Basic BIND Installation - featured image

Basic BIND Installation

This is a basic tutorial on how to install BIND, the Berkeley Internet Name Domain server, on a Ubuntu server in order 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 slaves as the public 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. Don’t be confused about that and change them to your IPs accordingly:

BIND weberdns.de Servers Master and Slaves

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 (will be published later), in which I am managing the keys only on the hidden primary but not on the slaves. No single access is possible from the public Internet to this server.
  • I am using only the private IPv4 or global IPv6 addresses through site-to-site VPN tunnels in order 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 in order to authenticate the zone transfers (even though not really mandatory since I am using VPN tunnels anyway). For each slave, I am using an 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).

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:

 

Master

The master 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 master. The allow-transfer statement lists the two slave servers that should be able to transfer the zone. Similarly the also-notify statement lists the slaves, 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 “ns1.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  in order 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. ūüėČ

Slave

The two slave 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 slave units.)

Now, the only portion to configure in order to be a slave 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 that:

DENIC NAST Test weberdns.de

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 slave 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, master and slaves. Here is a sample of my domain:

Zone Transfer Online Test

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 slaves and directed to the master, 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 (master to slave1, and master to slave2). Only if this “password” is present, the slave 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 slave 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 master server, open the named.conf file and add both keys one for each slave, 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 this IP addresses will still be possible without the key:

Same procedure on both slaves, 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 slave, 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 slave) for the following three scenarios:

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

That’s it. Hope this helps.

Links

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

Leave a Reply

Your email address will not be published. Required fields are marked *