DNS server setup

From Smith family
Jump to navigation Jump to search
Server setup
← Previous Next →
Protect SSH SSL certificates

Name servers are necessary so that the various client machines on the LAN can find the services offered by the servers. Setting up the Domain Name servers is a three-stage process. The first stage is to get the name servers running. The second stage is about making them secure by placing them in a chroot jail. The final stage is to make all the other machines on the LAN use these new nameservers, so that they can see the various servers on the LAN.

Getting the servers running

First, create the master nameserver on Server:

  • Install bind (make sure it's BIND9, not BIND (which is BIND8)):
 root@server:~# aptitude install bind9
This will install the configuration files in /etc/bind
  • Alter the /etc/bind/named.conf.options file to mention my ISP's nameservers
options {
       directory "/var/cache/bind";

       forwarders {
                  1.2.3.4;
                  1.2.3.5;
       };

       dnssec-validation auto;
       auth-nxdomain no;    # conform to RFC1035
       listen-on-v6 { any; };
       allow-recursion { localnets; };

};
if you have problems with your forwarders not implementing DNSSEC (error (insecurity proof failed) resolving './NS/IN' appearing in /var/log/syslog and intermittent DNS service), you may want to replace the dnssec lines with:
   // dnssec-validation auto;                                                                                                                               
   dnssec-enable no;
   dnssec-validation no;
  • Tell BIND about all the domains I want machines on my LAN to know about by mentioning them in /etc/bind/named.conf.local This is the file for the master server:
zone "domain.tld" {
       type master;
       file "/etc/bind/db.domain.tld";
       notify-source-v6 aaaa:bbbb:cccc:dddd::53;
       also-notify { aaaa:bbbb:cccc:dddd::54; 192.168.1.251; };
       allow-transfer { aaaa:bbbb:cccc:dddd::54; 192.168.1.251; };
};

zone "other-domain.org" {
       type master;
       file "/etc/bind/db.other-domain.org";
       notify-source-v6 aaaa:bbbb:cccc:dddd::53;
       also-notify { aaaa:bbbb:cccc:dddd::54; 192.168.1.251; };
       allow-transfer { aaaa:bbbb:cccc:dddd::54; 192.168.1.251; };
};

zone "1.168.192.in-addr.arpa" {
       type master;
       file "/etc/bind/db.1.168.192";
       notify-source-v6 aaaa:bbbb:cccc:dddd::53;
       also-notify { aaaa:bbbb:cccc:dddd::54; 192.168.1.251; };
       allow-transfer { aaaa:bbbb:cccc:dddd::54; 192.168.1.251; };
};
(note the absolute file names for the zone files)
and here is the file for the slave
zone "domain.tld" {
       type slave;
       file "db.domain.tld";
       masters { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
       allow-notify { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
};

zone "other-domain.org" {
       type slave;
       file "db.other-domain.org";
       masters { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
       allow-notify { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
};

zone "1.168.192.in-addr.arpa" {
       type slave;
       file "db.1.168.192";
       masters { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
       allow-notify { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
};

zone "d.d.d.d.c.c.c.c.b.b.b.b.a.a.a.a.ip6.arpa" {
    type slave;
    file "db.aaaa.bbbb.cccc.dddd";
    masters { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
    allow-notify { aaaa:bbbb:cccc:dddd::53; 192.168.1.252; };
};
Note the relative paths of the zone files. This is because BIND's default working directory is /var/cache/bind and the slave's zone files will be stored there. The AppArmour security module prevents BIND itself from saving files into /etc/bind/, so slave zone files can't be stored in that directory.
  • Now, create the zone files themselves, such as /etc/bind/db.domain.tld . Only do this on the master server, as the zone files will be automatically transferred to the slave server.
;
; BIND data file for the domain.tld domain
;
$ORIGIN domain.tld.
$TTL	60
@	IN	SOA	server.domain.tld. root.domain.tld. (
		      2022072401		; Serial
			      1d		; Refresh
			      1d		; Retry
			      4w		; Expire
			      1w )	; Negative Cache TTL
;
; server.domain.tld serves this domain as nameserver (IN NS)
;  and mail exchange (IN MX)
	 IN	NS 	ns1.domain.tld.
	 IN	NS 	ns2.domain.tld.
	 IN  MX	10 mail.domain.tld.

; define the base domain name
domain.tld.	IN AAAA	aaaa:bbbb:cccc:dddd::2
domain.tld.	IN A 192.168.1.252

; define other servers
localhost IN AAAA ::1
localhost IN A    127.0.0.1

;;;;;;;;;;;;
; machines
desktop		IN AAAA aaaa:bbbb:cccc:dddd::1
          IN A    192.168.1.251
server		IN AAAA aaaa:bbbb:cccc:dddd::2
          IN A    192.168.1.252
router 		IN AAAA 2a02:390:62aa::1
          IN A    10.191.106.1

; Name servers
ns1 IN  AAAA  aaaa:bbbb:cccc:dddd::53
    IN  A     192.168.1.252
ns2 IN  AAAA  aaaa:bbbb:cccc:dddd::54
    IN  A     192.168.1.251
; ns2 IN  CNAME desktop

; Web servers
www IN  AAAA  aaaa:bbbb:cccc:dddd::443
    IN  A     192.168.1.252
webmail		IN CNAME	www

; Mail servers
mail IN  AAAA  aaaa:bbbb:cccc:dddd::25
     IN  A     192.168.1.252
imap IN  AAAA  aaaa:bbbb:cccc:dddd::143
     IN  A     192.168.1.252
smtp		IN CNAME	mail

; Git
git IN  AAAA  aaaa:bbbb:cccc:dddd::9418
    IN  A     192.168.1.252
Note that all the CNAME records are only visible to machines within the LAN. If you want them visible to the outside world, you'll need to update the domain information with whoever hosts your DNS records for the wider world.
The reverse zone files, /etc/bind/db.1.168.192 /etc/bind/db.dddd.cccc.bbbb.aaaa are like this (note the full stops at the end of the host definition records):
;
; BIND reverse data file for LAN, IPv4
;
$ORIGIN 1.168.192.IN-ADDR.ARPA.
$TTL    3D
@       IN      SOA     server.domain.tld. root.domain.tld. (
                     2007042701         ; Serial
                             1w         ; Refresh
                             1d         ; Retry
                             4w         ; Expire
                             1w )       ; Negative Cache TTL
;
; define the authoritative name server
                NS      server.domain.tld.
                NS      desktop.domain.tld.

; our other hosts
1       IN      PTR     router.domain.tld.
251     IN      PTR     desktop.domain.tld.
252     IN      PTR     server.domain.tld.
@       IN      NS      localhost.

;
; BIND reverse data file for LAN, IPv6
;

$TTL	3D
@	IN	SOA	server.domain.tld. root.domain.tld. (
		      2022072401		; Serial
			      1d		; Refresh
			      1d		; Retry
			      4w		; Expire
			      1w )	; Negative Cache TTL

;
; define the authoritative name server
		 NS	server.domain.tld.
		 NS	desktop.domain.tld.

; our other hosts
1	IN	PTR	router.domain.tld.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    router.domain.tld.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    desktop.domain.tld.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    server.domain.tld.
3.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    www.domain.tld.
3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    ns1.domain.tld.
4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    ns2.domain.tld.
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    mail.domain.tld.
3.4.1.0.0.0.0.0.0.0.0.0.0.0.0.0    PTR    imap.domain.tld.
8.1.4.9.0.0.0.0.0.0.0.0.0.0.0.0    PTR    git.domain.tld.
(Note the full stops after all the domain names.)
  • Update /etc/network/interfaces to tell dnsmasq about the nameservers
  1. The primary network interface
auto enp0s7
iface enp0s7 inet static
       address 192.168.1.251
       netmask 255.255.255.0
       network 192.168.1.0
       broadcast 192.168.1.255
       gateway 192.168.1.1
       # dns-* options are implemented by the resolvconf package, if installed
       dns-nameservers 192.168.1.252 192.168.1.251
       dns-search domain.tld
  • Restart bind:
root@server:~# systemctl restart bind9.service
and check that it works:
root@server:~# host desktop.domain.tld
root@server:~# host server.domain.tld server.domain.tld
root@server:~# host www.google.com desktop.domain.tld
(and repeat for other hosts and both nameservers). You may need to reboot the master DNS server before the zone files transfer properly.

Chrooting the nameservers

I used to do this for security. But now AppArmor and SELinux are here, so I don't bother. It's just one more thing to go wrong.

Update the router

Finally, update the router to point to these nameservers, not the ones at the ISP. Normally, the router picks up the ISP's nameservers when it connects to the ISP. The router then acts as a recursive nameserver for the machines on the LAN, and it tells them when machines register with DHCP.

You should be able to tell the router to use Server and Desktop as the nameservers it uses instead. Server and Desktop both know about the ISP's nameservers for finding IPs of machines outside the LAN. This means that the sequence of DNS requests is:

  1. DHCP-connected machine asks the router for an IP number,
  2. Router asks Server for the IP number,
  3. Server asks the ISP's nameserver for the IP number,
  4. ISP's nameserver finds it from somewhere and returns it.

For DD-WRT, the settings to use are:

  • Router IP
    • Local DNS: 192.168.0.252
  • Network Address Server Settings (DHCP)
    • Static DNS 1: 192.168.0.252
    • Static DNS 2: 192.168.0.251
    • Static DNS 3: 0.0.0.0
    • WINS: 0.0.0.0
    • Use DNSMasq for DHCP: OFF
    • Use DNSMasq for DNS: OFF
    • DHCP-Authoritative: OFF

See also

For a tutorial on how to set up nameservers, read BIND for the Small LAN by Paul Heinlein.

Other sources are the book Pro DNS and Bind, which is a great resource on the intricacies of BIND (especially Chapter 5 on BIND and Chapter 6 giving example setups).

There is also the Ubuntu BIND9 howto and the Debian howtos on setting up a BIND server and chrooting a BIND server.

Finally, the /usr/share/doc/bind9/README.Debian.gz file on your machine's local disk has some good pointers.

Retrieved from "https://www.njae.me.uk/mediawiki/index.php?title=DNS_server_setup&oldid=3001"