When you create multiple A records for the same name, then bind will do a round robin of the order in which the records are returned. This allows the use of DNS as a load balancer between hosts, since clients will usually take the first ip-address offered.

Consider this example from the /etc/bind/db.paul.local zone configuration file. There are two A records for www pointing to two distinct ip addresses.

root@debian7:~# grep www /etc/bind/db.paul.local
www             IN      A       10.104.33.30
www             IN      A       10.104.33.31

Below a screenshot of nslookup querying a load balanced A record. Notice the order of ip addresses returned.

root@debian7:~# nslookup www.paul.local 10.104.33.30
Server:         10.104.33.30
Address:        10.104.33.30#53

Name:   www.paul.local
Address: 10.104.33.31
Name:   www.paul.local
Address: 10.104.33.30

root@debian7:~# nslookup www.paul.local 10.104.33.30
Server:         10.104.33.30
Address:        10.104.33.30#53

Name:   www.paul.local
Address: 10.104.33.30
Name:   www.paul.local
Address: 10.104.33.31

Try to set up a website on two web servers (with a small difference so you can distinguish the websites) and test the round robin.

You can delegate a child domain to another DNS server. The child domain then becomes a new zone, with authority at the new dns server.

When delegation is properly set up, then clients that query your parent zone will also be able to resolve the delegated child zones.

We have another Linux server named debian7b and we want to make it responsible for the child domain test42.paul.local.

Note the name of the servers in the screenshots are either debian7 (hosting the parent domain) or debian7b (hosting the child domain).

We start by adjusting the /etc/bind/named.comf.local file (on the server hosting the parent domain) to make sure that no forwarder will be used when resolving authoritative names.

root@debian7:~# grep -A4 paul.local /etc/bind/named.conf.local
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local";
        allow-update { none; };
        allow-transfer { 10.104.15.20; };
        forwarders { };
};
root@debian7:~#

Technically, you could also set allow-transfer to { any; }; while troubleshooting and then refine it later, but this is not needed for delegation.

Then we add the delegation to our zone database:

root@debian7:~# tail -3 /etc/bind/db.paul.local
$ORIGIN test42.paul.local.
@       IN      NS      ns2.test42.paul.local.
ns2     IN      A       10.104.33.31    ; the glue record
root@debian7:~#

Don't forget to restart bind and verify /var/log/syslog.

root@debian7:~# service bind9 restart
Stopping domain name service...: bind9.
Starting domain name service...: bind9.
root@debian7:~# grep paul.local /var/log/syslog | cut -c28- | tail -2
named[3202]: zone paul.local/IN: loaded serial 2014100801
named[3202]: zone paul.local/IN: sending notifies (serial 2014100801)
root@debian7:~#

Note that on your terminal you can type tail -40 /var/log/syslog because the only reason I use grep, cut and tail -2 is to limit the size of the screenshots in this book.

Next we create a zone database file on the second server, as seen in this screenshot:

root@debian7b:~# cat /etc/bind/db.test42.paul.local
; child zone for classroom teaching
$TTL    86400
$ORIGIN test42.paul.local.
@       IN      SOA     ns2.test42.paul.local. root.test42.paul.local. (
                        2014100802      ; Serial
                        1h              ; Refresh
                        1h              ; Retry
                        2h              ; Expire
                        900 )           ; Negative Cache TTL
;
; name servers
;
        IN      NS      ns2.test42.paul.local.
        IN      NS      debian7b.test42.paul.local.
;
; servers
;
ns2             IN      A       10.104.33.31
debian7b        IN      A       10.104.33.31
testsrv         IN      A       10.104.33.31
root@debian7b:~#

The second server also needs a zone definition in named.conf.local, followed by a restart of bind.

root@debian7b:~# cat /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";

zone "test42.paul.local" IN {
        type master;
        file "/etc/bind/db.test42.paul.local";
        allow-update { none; };
        allow-transfer { any; };
};
root@debian7b:~#

Testing on the parent server:

root@debian7:~# dig ns1.paul.local +short
10.104.33.30
root@debian7:~# dig ns2.test42.paul.local +short
10.104.33.31
root@debian7:~# dig debian7b.test42.paul.local +short
10.104.33.31

Suppose you want to answer dns queries depending on who is asking. For example when someone from the 10.104.15.0/24 network (managed by Jesse) asks for the A record www.paul.local, then dns answers with 10.104.33.30. But when someone from the 10.104.42.0/24 network (managed by Keith) asks for the same A record of www.paul.local, he will get 10.104.33.31 as an answer.

A split-horizon setup can be used to redirect people to local copies of certain services.

In this example we want to decide on specific answers for two networks (Jesse's and Keith's) and prevent them from using our dns server for recursion, while maintaining the capability to resolve the internet and our paul.local zone from our own network.

We start by creating three view clauses in named.conf.local.

root@debian7:/etc/bind# cat named.conf.local
view "paul" {
match-clients { 10.104.33.0; localhost; };
include "/etc/bind/named.conf.default-zones";
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local";
        allow-update { none; };
        };
};      // end view internal

view "jesse" {
match-clients { 10.104.15/24; };
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local.jesse";
        allow-update { none; };
        };
};      // end view jesse

view "keith" {
match-clients { 10.104.42/24; };
zone "paul.local" IN {
        type master;
        file "/etc/bind/db.paul.local.keith";
        allow-update { none; };
        };
};      // end view keith

Note that we included the default-zones in the internal zone. It is mandatory to put all zones inside views when using a view.

The zone files are identical copies, except for the www record. You can see that the round robin is still active for internal users, computers from 10.104.15.0/24 (Jesse) will always receive 10.104.33.30 while computers from 10.104.42.0/24 (Keith) will receive 10.104.33.31.

root@debian7:/etc/bind# grep www db.paul.local db.paul.local.[jk]*
db.paul.local:www               IN      A       10.104.33.30
db.paul.local:www               IN      A       10.104.33.31
db.paul.local.jesse:www         IN      A       10.104.33.30
db.paul.local.keith:www         IN      A       10.104.33.31

All the dns things below this paragraph are old and in urgent need of review.

root@ubu1010srv:/etc/bind# grep -A4 arpa named.conf.local 
zone "1.168.192.in-addr.arpa" {
	type master;
	notify no;
	file "/etc/bind/db.192";
};

root@ubu1010srv:/etc/bind# cat db.192 
;
; BIND reverse data file for 192.168.1.0/24 network
;
$TTL	604800
@	IN	SOA	ns.cobbaut.paul root.cobbaut.paul. (
			20110516	; Serial
			 604800		; Refresh
			  86400		; Retry
			2419200		; Expire
			 604800 )	; Negative Cache TTL
;
@	IN	NS	ns.
37	IN	PTR	ns.cobbaut.paul.
1	IN	PTR	anya.cobbaut.paul.
30	IN	PTR	mac.cobbaut.paul.
root@ubu1010srv:/etc/bind# 

root@ubu1010srv:/etc/bind# dig 1.168.192.in-addr.arpa AXFR

zone "1.168.192.in-addr.arpa" {
        type master;
        notify no;
        file "/etc/bind/db.192";
};

root@ubu1010srv:/etc/bind# nsupdate
> server 127.0.0.1
> update add mac14.linux-training.be 86400 A 192.168.1.23
> send
update failed: REFUSED

view "internal" {
match-clients { 192.168.42/24; };
recursion yes;
...

};

view "external" {
match-clients { any; };
recursion no;
...

};

options {
      allow-query { 192.168.42.0/24; localhost; };
};

zone "cobbaut.paul" {
      allow-query { any; };
};

options {
        allow-recursion { 192.168.42.0/24; localhost; };
};