In Fire We Trust

This is the third part of series of articles in which i will explain how to create the perfect SOHO router. I have to note that this is my idea of a perfect router with all the good and bad points stemming from it.

The series will comprise of the following articles:

• Basic hints, ideas, needed services and some thoughts - Here i will try to argument myself upon the choice of software and services for the router
• Base install - i will describe the way our system will be installed and minimized
• Configuration of DNS and DHCP services - here i will describe with arguments what i think is the best configs for the task
• Configure the routing - here is the heart of our router. I will suggest some tricks that make the life easier, also some pointers for more specific stuff
• Configuring very basic monitoring system
• Extending our router - i will describe some small things that make our life tad easier, smooth and not so demanding

Having already installed our router it is time to start configuring it. We are starting with the DNS and DHCP serviced because of:

• It is a good example
• In this way we will ensure initial security and ease of configurability
• We are still able to experiment easily

Why we need DNS
DNS is used to discover the relations between names and ip addresses. The system itself is a vast distributed database in which all the names in the world are organized. It is usefull to have our own DNS due to:

• Possibility to create a fake domain
• Speedup in replies
• Caching of the replies
• Partial independence from our ISP

Why we need DHCP
DHCP is a protocol for dynamic configuration of the network part of our operating system. With it’s help we can set a range of parameters for the network of the client machines. Also this protocol saves us from manually changing the settings to each and every machine on a simple change. With it’s help we can set the following settings (incomplete list):

• IP address
• DNS server
• Server for network boot
• Default route to reach the internet
• Time server
• TTL
• Maximum packet size
• others

Possible variants
As almost everything in the GNU/Linux world this task can be accomplished in few different ways. The two most used variants are: separate DNS and DHCP software servers; single software server which can handle DNS and DHCP. The most popular solutions for small networks (30 - 50 machines) are:

• bind9 + dhcpd
• dnsmasq

Here we will describe configurations for both the variants. My personal prefference goes to bind9 and dhcpd

Configuration of dhcpd
We take the following presumptions in the process of confiuration:

• Our internal network is 10.42.3.0/24
• Our internal interface is eth1
• Our DNS is at 10.42.3.1
• Additionaly we serve another DNS from our ISP which is at 1.2.3.4
• Our gateway is at address 10.42.3.1
• All our machines belong to a nonexistent domain internal.tld
• We will provide additional settings for network unification

After all the above here is a sample dhcp configuration for our server
/etc/dhcpd.conf

#
# Sample configuration file for ISC dhcpd for Debian
#
# $Id: dhcpd.conf,v 1.4.2.2 2002/07/10 03:50:33 peloy Exp $
#
 
# option definitions common to all supported networks...
# without this the dhcp server won't operate correctly
authoritative;
 
# our nonexistent domain to which we will belong
option domain-name "internal.tld";
# our dns server. We give only him here for extensibility of the config
option domain-name-servers 10.42.3.1;
 
# netmask. No need for the client to guess what they should set
option subnet-mask 255.255.255.0;
# for how much time they can hold the address
default-lease-time 14400;
# max time they can keep the address if the server is down
max-lease-time 86400;
 
# the network from which we serve addresses
subnet 10.42.3.0 netmask 255.255.255.0 {
  # the range of addresses we will serve
  range 10.42.3.2 10.99.3.254;
  # our DNS servers (this time both)
  option domain-name-servers 10.99.3.1, 1.2.3.4;
  # and the fake domain
  option domain-name "internal.tld";
  # the router (gateway)
  option routers 10.42.3.1;
  # netmask
  option subnet-mask 255.255.255.0;
  # where to send queris to all machines
  option broadcast-address 10.42.3.255;
  # setting the TTL (windows does not obey)
  option default-ip-ttl 64;
  option default-tcp-ttl 64;
  # time shift from GMT
  option time-offset 7200;
  # node type to set in MS network
  option netbios-node-type 8;
}

All in all this is a good start. You can see that there is certain overlap of the configurations for DNS, netmask and domain. This is done on purpose. This will help us if at later point we decide to segment our network. If such need arises it will be enough just to split the section subnet in few parts and serve different settings from each of them. As a rule of thumb allways define as much parametters as possible on the highest level possible (ex: globally). This way at a later stage there will be less and easier maintenace on the configuration.

It has to be noted that the server should listen only on the internal interface (eth1). This can be accomplished with a setting in the file /etc/default/dhcp telling the deamon at which interfaces to listen on.

Frankly said that completes the configuration of our dhcpd.

Configuration of bind9
This will be our DNS server. For its configuration we start from the same presumptions as for the DHCP server. As an addition we will create our fake nonexistant domain internal.tld.

The configuration of the deamon is split in few files, namely:

• /etc/bind/named.conf - main configuration. It usually just includes other files
• /etc/bind/named.conf.options - here we can find options tunning our server behavior
• /etc/bind/named.conf.local - here are the definitions of our zones
• Zone files - those are our zones

We will show the configurations for our server and the zones we have created, but skip the standard existing ones.

/etc/bind/named.conf

// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in /etc/bind/named.conf.local
 
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";

/etc/bind/named.conf.options

options {
        // directory which we will use as a working place. If we supply relative filename
        // it will be searched in this dir
        directory "/var/cache/bind";
 
        // If there is a firewall between you and nameservers you want
        // to talk to, you might need to uncomment the query-source
        // directive below.  Previous versions of BIND always asked
        // questions using port 53, but BIND 8.1 and later use an unprivileged
        // port by default.
 
        query-source address * port 53;
 
        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.
 
        forwarders {
                1.2.3.4;
        };
 
        auth-nxdomain no;    # conform to RFC1035
        // we won't use IPv6
        listen-on-v6 { none; };
        // Don't allow recursion. I.e. don't answer for domains we don't know of
        // this option will later be overriden
        recursion no;
        // due to the fact we don't listen on IPv6 and accordingly don't define zones for it
        // a few quite irritating lines show up in the logs. This takes care of them.
        empty-zones-enable no;
};

/etc/bind/named.conf.local

//
// Do any local configuration here
//
 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
 
// Access list. localhost should be in it.
acl internal {
        10.42.3.0/24;
        127.0.0.0/8;
};
 
// view. This is a new possibility of bind allowing separation of information
// according to where we come from
view "internal" {
        // from this view only clients in the acl can receive responses
        match-clients { internal; };
        // now we can answer for domains we don't know
        recursion yes;
 
        // our nonexistent domain
        zone "internal.tld" {
                type master;
                // where is the zone itself
                file "/etc/bind/internal.tld-forward";
                // if we enable dynamic updates of the info in DNS
                // only clients matching the acl can do it.
                allow-transfer { internal; };
                allow-update { internal; };
        };
 
         // this is our reverse zone
        zone "3.99.10.in-addr.arpa" {
                type master;
                file "/etc/bind/internal.tld-reverse";
                allow-transfer { internal; };
                allow-update { internal; };
        };
 
        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "/etc/bind/db.root";
        };
 
        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912
 
        zone "localhost" {
                type master;
                file "/etc/bind/db.local";
        };
 
        zone "127.in-addr.arpa" {
                type master;
                file "/etc/bind/db.127";
        };
 
        zone "0.in-addr.arpa" {
                type master;
                file "/etc/bind/db.0";
        };
 
        zone "255.in-addr.arpa" {
                type master;
                file "/etc/bind/db.255";
        };
};

This finishes the configuration of our DNS server. As you can see it listens on all interfaces but can respond only on queries comming from the inside of our network. The standard place for the logs in debian is /var/log/daemon.log. Now we just have to define our zones and we are set.

internal.tld - /etc/bind/internal.tld-forward

; BIND db file for internal.tld
; default time to live for each RR
$TTL 86400
 
; RR which defines us as owners of the domain
@       IN      SOA     perfect-soho-r01.internal.tld.      root. (
                        2007060101     ; serial number YYMMDDNN
                        28800           ; Refresh
                        7200            ; Retry
                        864000          ; Expire
                        86400           ; Min TTL
                        )
                ; our DNS. This is called glue
                NS      perfect-soho-r01.internal.tld.
 
; if a name is not fully qualified, append this
$ORIGIN internal.tld.
 
perfect-soho-r01  IN      A       10.42.3.1
; alias of our router
gate IN CNAME perfect-soho-r01

3.42.10.in-addr.arpa - /etc/bind/internal.tld-reverse

; BIND reverse data file for internal.tld
$TTL    86400
@       IN      SOA     garota.internal.tld. root. (
                     2007060101         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                          86400 )       ; Negative Cache TTL
 
@       IN      NS      perfect-soho-r01.internal.tld.
1       IN      PTR     perfect-soho-r01.internal.tld.

That completes the configuration for bind9.

Configuration of dnsmasq
dnsmasq is a combination of dns and dhcp server suitable for small networks. It has low memory footprint, can be configured quickly and easily. I am not quite used to it, but after few consultations with man this seems suitable

# Configuration file for dnsmasq.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
 
# Never forward plain names (with a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv
 
# Uncomment this to filter useless windows-originated DNS requests
# Note that (amongst other things) this blocks all SRV requests,
# so don't use it if you use eg Kerberos.
filterwin2k
 
# Add domains which you want to force to an IP address here.
# The example below send any host in doubleclick.net to a local
# webserver.
# a bit of spam/ad blocking
address=/doubleclick.net/127.0.0.1
 
# If you want dnsmasq to change uid and gid to something other
# than the default, edit the following lines.
#user=
#group=
 
# If you want dnsmasq to listen for requests only on specified interfaces
# (and the loopback) give the name of the interface (eg eth0) here.
# Repeat the line for more than one interface.
interface=eth1
 
# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
expand-hosts
 
# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
#     as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
#    domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
domain=internal.tld
 
# Uncomment this to enable the integrated DHCP server, you need
# to supply the range of addresses available for lease and optionally
# a lease time. If you have more than one network, you will need to
# repeat this for each network on which you want to supply DHCP
# service.
dhcp-range=10.42.3.2,10.42.3.254,255.255.255.0,4h
 
# If this line is uncommented, dnsmasq will read /etc/ethers and act
# on the ethernet-address/IP pairs found there just as if they had
# been given as --dhcp-host options. Useful if you keep
# MAC-address/host mappings there for other purposes.
read-ethers
 
# Send options to hosts which ask for a DHCP lease.
# See RFC 2132 for details of available options.
# Note that all the common settings, such as netmask and
# broadcast address, DNS server and default route, are given
# sane defaults by dnsmasq. You very likely will not need any
# any dhcp-options. If you use Windows clients and Samba, there
# are some options which are recommended, they are detailed at the
# end of this section.
# For reference, the common options are:
# subnet mask - 1
# default router - 3
# DNS server - 6
# broadcast address - 28
dhcp-option=6,10.42.3.1,1.2.3.4
# Set the default time-to-live
dhcp-option=23,64
 
# The following DHCP options set up dnsmasq in the same way as is specified
# for the ISC dhcpcd in
# http://www.samba.org/samba/ftp/docs/textdocs/DHCP-Server-Configuration.txt
# adapted for a typical dnsmasq installation where the host running
# dnsmasq is also the host running samba.
# you may want to uncomment them if you use Windows clients and Samba.
dhcp-option=19,0           # option ip-forwarding off
#dhcp-option=44,0.0.0.0     # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
#dhcp-option=45,0.0.0.0     # netbios datagram distribution server
dhcp-option=46,8           # netbios node type
dhcp-option=47             # empty netbios scope.
 
# Set the DHCP server to authoritative mode. In this mode it will barge in
# and take over the lease for any client which broadcasts on the network,
# whether it has a record of the lease or not. This avoids long timeouts
# when a machine wakes up on a new network. DO NOT enable this if there's
# the slighest chance that you might end up accidentally configuring a DHCP
# server for your campus/company accidentally. The ISC server uses the same
# the same option, and this URL provides more information:
# http://www.isc.org/index.pl?/sw/dhcp/authoritative.php
dhcp-authoritative
 
# Normally responses which come form /etc/hosts and the DHCP lease
# file have Time-To-Live set as zero, which conventionally means
# do not cache further. If you are happy to trade lower load on the
# server for potentially stale date, you can set a time-to-live (in
# seconds) here.
local-ttl=600
 
# If you want dnsmasq to detect attempts by Verisign to send queries
# to unregistered .com and .net hosts to its sitefinder service and
# have dnsmasq instead return the correct NXDOMAIN response, uncomment
# this line. You can add similar lines to do the same for other
# registries which have implemented wildcard A records.
#bogus-nxdomain=64.94.110.11
 
#log-queries 

I don’t say that this configuration is perfect but i am not such a guru on dnsmasq.

Conclusion
After we have finished this we should have a prety stable machine, with all the services running. It just still can’t route. Now is a good time for some rest because we will be setting up routing and filtering.

The Series continues with The Perfect SOHO router - Part 4