This is a basic tutorial on how to install BIND, the Berkeley Internet Name Domain server, on a Ubuntu server to run it as an authoritative DNS server. It differs from other tutorials because I am using three servers (one as a hidden primary and two secondaries as the publicly accessible ones), as well as some security such as denying recursive lookups and public zone transfers, as well as using TSIG for authenticating internal zone transfers. That is, this post is not an absolute beginner’s guide.

The basic environment looks like that. Note that I am showing my real IP addresses, private and public ones. Don’t be confused about that and change them to your IPs accordingly:

Some notes about the installation of the servers:

• My domain for these test servers is weberdns.de.
• The main motivation for the hidden primary approach comes from DNSSEC (see other posts), in which I am managing the keys only on the hidden primary but not on the secondaries. No single access is possible from the public Internet to this primary server.
• However, note that the Start-of-Authority (SOA) record lists this ns0.weberdns.de server though, while the NS records only list the two secondary name servers ns1.weberdns.de and ns2.weberdns.de.
• I am using only the private IPv4 or global IPv6 addresses through site-to-site VPN tunnels to transfer the zones between the DNS servers. This brings encryption when traversing the Internet, as well as appropriate security policies on the intermediate firewalls.
• By default, each server sends notifications to all other NS servers in case of a zone change. In my case, the notifications are set to “explicit” to only notify the private IPv4 addresses specified in the zone configuration “also-notify { };” and not the public ones.
• TSIG is used to authenticate the zone transfers (even though not really mandatory since I am using VPN tunnels anyway). For each secondary, I am using a unique key.
• Public zone transfers (AXFR) are disabled globally. Only servers that authenticated with their key within the “allow-transfer { };” statement are allowed to transfer the zone.
• Per-zone statistics are enabled on all servers.
• I am using Ubuntu servers version 14.04 LTS either on VMs or on hardware. Of course, they have static (NATted) IPv4 and IPv6 addresses. The bind9 package from Ubuntu at the time of writing is version 9.9.5-3ubuntu0.8-Ubuntu (June 2016).
• Throughout my blogposts, I am using the terms “primary/secondary” rather than “master/slave” to omit the outdated slavery here.

BIND Installation

To install the BIND package simply use the following two statements:

All configuration files are stored in the folder /etc/bind/ .

The started process is called “named“. It listens on udp and tcp port 53, each for IPv4 and IPv6:

To view syslog messages, grep for the “named” process:

 

Primary (Master)

The primary server is the one on which the zone files are maintained. At first, some options are set to secure the authoritative server. These are set within the named.conf.options file (in the /etc/bind/ folder).

Add the following options:

Then, add a zone statement inside the named.conf.local file:

In my case a zone weberdns.de of type primary. The allow-transfer statement lists the two secondary servers that should be able to transfer the zone. Similarly, the also-notify statement lists the secondaries, too, in order to notify them in case of a zone update.

Finally, the zone file must be created. I am using the template from Hetzner. All relevant statements are already explained there, so I won’t repeat them here.

This is my basic zone file. The SOA record starts with “ns0.weberdns.de”. There are two NS records (ns1. and ns2.) for this domain, as well as an MX record. Some examples of A, AAAA, CNAME, and TXT records are also shown. And remember to increment the serial number after each modification of the zone file! ;)

After these steps, the BIND server must be restarted for all changes to work:

A check of the configuration can be done with  named-checkconf -z  . If no errors occur, everything works fine.

For updates of the zone file, a reload of BIND fits. No restart is required. The reload can be triggered by either one of these two commands:

A basic test can be done with the dig tool, such as:

Note the “aa” flag in line 8 which indicates that this is an “authoritative answer”.

To view the statistics, run  sudo rndc stats to dump the stats into the following file: cat /var/cache/bind/named.stats . The new statistics are always appended to this file and are listed between the following strings, while the number in brackets is the unixtime:

Great so far. ;)

Secondary

The two secondary servers are installed in the same way as the primary. The additional options should be the following ( sudo nano named.conf.options ):

Note that it is REALLY crucial to put in these lines, at least the “allow-transfer none” one. Otherwise, the zone is fully loadable through an axfr request. (A painful mistake is to only place this statement at the hidden primary but to forget it on the secondary units.)

Now, the only portion to configure to be a secondary is inside the named.conf.local file.

In my case, it only lists the following lines:

After a restart of the service ( sudo service bind9 restart ), everything is ready. Asking the localhost should work, e.g.: dig @localhost mail.weberdns.de .

The resource records are stored in the following path: /var/cache/bind/. Note that these files are not readable, but can be converted into a textfile with:

This reads the raw database (-f raw) and includes the journal file (-j). It outputs text (-F text) into the file (-o outputfilename). With  cat db.weberdns.de.txt   you can see your RRs.

Parent Zone: Glue Records

To become the authoritative servers, the names and/or IP addresses of the nameservers must be configured at the parent zone, in my case the DENIC which is responsible for *.de. They offer a good online check for domain servers (Nameserver Predelegation Check Web Interface) which tests the nameservers to see if everything is accessible (firewalls with udp/tcp port 53) and configured correctly (SOA record values, …). In my case, this looks like this:

Since my NS servers for “weberdns.de” are called “ns1.weberdns.de” and “ns2.weberdns.de”, (which won’t be resolvable if only these FQDNs are known), the entries for these nameservers are stored with their glue records, i.e., the name and the IP addresses.

After this step was done, a whois for weberdns.de looks like:

The Internet is now able to ask my two secondary name servers for everything ending with .weberdns.de. Great again. This can easily be tested with dig +trace from any machine that has Internet access, e.g.:

Zone Transfers

At first, it is crucial to test that zone transfers of your servers are not available from the Internet. The Zone Transfer Online Test can be used for this purpose. This should fail because the “allow-transfer” options are already configured for both server types, primary and secondary. Here is a sample of my domain:

Dig can be used to test the zone transfers, too, such as:

Of course, this command will/must work if it is issued from one of the secondaries and directed to the primary, in my case:

To authenticate the zone transfers, TSIG can be used. (This won’t be needed in my case, because I am already using private site-to-site VPNs for the connections between my servers. However. ;)) With TSIG, a shared secret is configured on any server pair (primary to secondary1, and primary to secondary2). Only if this “password” is present, the secondary is able to transfer the zone. Note that this is not encryption (confidentiality), but only authentication.

At first, the keys must be generated. Note the last option which is the key-name, in this example case “key-ns1”:

I am using two different keys for both secondary servers. That is, I generated the following keys. Note that the key values in both files (*.key and *.private) are the same keys. (And no, these are not my actual keys, but only demos):

On the primary server, open the named.conf file and add both keys one for each secondary, such as:

Furthermore, open the named.conf.local and change the “allow-transfer” statement to only allow connections with these keys. The IP addresses from the servers must be omitted, for example, comment them out. Otherwise, connections from these IP addresses will still be possible without the key:

Same procedure on both secondaries, of course only with the single needed key, e.g., key-ns1 and key-ns2. Furthermore, the “server” statement must be configured. Open the named.conf on the first secondary, ns1, and add these lines:

And similarly on ns2:

Now, restart all bind services  sudo service bind9 restart and you’re done.

A dig test w/o the key will not work anymore:

But with the key (-y option), the zone transfer works again:

Note the different syslog messages (captured on the secondary) for the following three scenarios:

Finally, here are some Wireshark screenshots for different notifications and zone transfers, with and without TSIG. See the descriptions beneath them for more details:

If you want to have a look at the pcaps by yourself, here we go (7zipped, 12 KB):

That’s it. Hope this helps.

Links

Other BIND tutorials are here or here [DE]. The following links are more specific:

• BIND 9 documentation
• BIND 9 list of statements
• Hetzner Standard Zone File Template
• Zone Transfer Online Test
• Secure Zone transfer in BIND using TSIG (Transaction Signatures)
• (Online) DNSWatch: DNS Lookups  & Performance Monitoring
• (Linux) DNS Diagnostics and Performance Measurement Tools
• DENIC Nameserver Predelegation Check Webinterface (NAST)

Featured image “Anna-Amalia-Bibliothek Weimar B” by Fofarama is licensed under CC BY 2.0.