Bind9 offers a wealth of features, most of which you probably won’t need, but over time the complexities of an organization usually mean you’ll need to get to grips with things.

Here I’ll introduce a somewhat complex bind9 configuration, explain the background and provide an overview of how things work.

Organization setup

So your organization has a new office with a printer and a couple of file servers. The office is connected via a branch office VPN connection to two other offices. Most services users need access to are located in one of these remote offices and each office has a DNS server.

Office-A Configuration

network: 10.30.0.0/16
DNS IP: 10.30.0.2
How does this configuration work?
   1. clients on the local network can resolve IP addresses from the local internal.office-a.com domain
   2. requests for addresses on the internal.office-b.com domain will be resolved locally using the
        db.internal.office-b.com.zone "slave" file
   3. requests for addresses on the internal.office-c.com domain will be forwarded to the DNS server
        in office-C on 10.60.0.2

named.conf.local
zone "internal.office-a.com" IN {
  type master;
  file "internal.office-a.com.zone";
};
zone "10.30.in-addr.arpa" {
  type master;
  file "db.internal.office-a.com.rev";
};
zone "internal.office-b.com" {
    type slave;
    file "db.internal.office-b.com.zone";
    masters { 10.7.0.2; };
};
zone "internal.office-c.com" {
    type forward;
    forward only;
    forwarders { 10.60.0.2; };
};

named.conf.options
options {
        directory "/var/bind/";
        dnssec-enable yes;
        dnssec-validation yes;
        auth-nxdomain no;    # conform to RFC1035
        listen-on port 53 { localhost; 10.30.0.0/16; 10.7.0.0/16; 10.60.0.0/16; };
        allow-query { localhost; 10.30.0.0/16; 10.7.0.0/16; 10.60.0.0/16; };
        forwarders { 8.8.8.8; };
        recursion yes;
};

internal.office-a.com zone file
$TTL 86400
@ IN SOA internal.office-a.com root.internal.office-a.com (
  2022111801
  3600
  900
  604800
  86400
)
@                       IN NS dns
dns                     IN A 10.30.0.2
printer                 IN A 10.99.99.99

Office-B Configuration

network: 10.7.0.0/16
DNS IP: 10.7.0.2
How does this configuration work?
   1. clients on the local network can resolve IP addresses from the local internal.office-b.com domain
   2. requests for addresses on the internal.office-a.com domain will fail
   3. requests for addresses on the internal.office-c.com domain will be forwarded to the DNS server
        in office-C on 10.60.0.2

named.conf.local
zone "internal.office-b.com" IN {
  type master;
  file "internal.office-b.com.zone";
  allow-transfer { 10.7.0.2; };
  also-notify { 10.7.0.2; };
};
zone "7.10.in-addr.arpa" {
  type master;
  file "db.internal.office-b.rev";
};
zone "internal.office-c.com" {
    type forward;
    forward only;
    forwarders { 10.60.0.2; };
};

named.conf.options
options {
        directory "/var/bind";
        dnssec-enable yes;
        dnssec-validation yes;
        auth-nxdomain no;    # conform to RFC1035
        listen-on port 53 { localhost; 10.30.0.0/16; 10.7.0.0/16; 10.60.0.0/16; };
        allow-query { localhost; 10.30.0.0/16; 10.7.0.0/16; 10.60.0.0/26; };
        forwarders { 8.8.8.8; };
        recursion yes;
};

internal.office-b.com zone file
$TTL 86400
@ IN SOA internal.office-b.com root.internal.office-b.com (
  2022111802
  3600
  900
  604800
  86400
)
@                       IN NS dns
dns                     IN A 10.7.0.2
pc1                     IN A 10.7.0.4
pc2                     IN A 10.7.0.5
pc3                     IN A 10.7.0.6
server100               IN A 10.7.0.217
server101               IN A 10.7.0.218
server102               IN A 10.7.0.219
server103               IN A 10.7.0.220

Office-C Configuration

network: 10.60.0.0/16
DNS IP: 10.60.0.2
How does this configuration work?
   1. clients on the local network can resolve IP addresses from the local internal.office-c.com domain
   2. requests for addresses on the internal.office-a.com domain will be fail
   3. requests for addresses on the internal.office-b.com domain will fail

named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
zone "internal.office-c.com" IN {
  type master;
  file "internal.office-c.com.zone";
};
zone "60.10.in-addr.arpa" {
  type master;
  file "db.internal.office-c.com.rev";
};

named.conf.options
options {
        directory "/var/bind";
        dnssec-enable yes;
        dnssec-validation yes;
        auth-nxdomain no;    # conform to RFC1035
        listen-on port 53 { localhost; 10.30.0.0/16; 10.7.0.0/16; 10.60.0.0/16; };
        allow-query { localhost; 10.30.0.0/16; 10.7.0.0/16; 10.60.0.0/26; };
        forwarders { 8.8.8.8; };
        recursion yes;
};

internal.office-b.com zone file
$TTL 86400
@ IN SOA internal.office-b.com root.internal.office-b.com (
  2022111605
  3600
  900
  604800
  86400
)
@                       IN NS dns
dns                     IN A 10.60.0.2
active-directoy-pc      IN A 10.60.0.5
centos-server           IN A 10.60.0.217
linux-server            IN A 10.60.0.117
latest_client           IN A 10.60.0.102

FQDNs across multiple DNS zones

As explained earlier the resources most used by the people in Office A are located in Office B, so in order for these people to access these resources they would need to use the FQDN of the resource.

However, if you want to allow the use of a hostname without having to use the complete FQDN then you can make use of multiple DNS search suffixes.

In windows using a static IP you can do this by navigating to the adapter settings, IP4, Advanced, DNS, Append these DNS suffixes (in order), and adding internal.office-a.com and internal.office-b.com. In this example, a user based in Office A would reference printer as either printer or printer.internal.office-a.com, and server100 as either server100 or server100.internal.office-b.com.