Configure Authoritative Name Server Using BIND on Ubuntu

Table of Contents

• Introduction
• Requirements
• Prepare Servers
• Install BIND
• Configure Primary Server
• Create Zone File
• Configure Secondary Server
• Test DNS Resolution
• Modify Zone File
• Reverse DNS
• Troubleshoot DNS Issues

Introduction

BIND is the one of the most popular DNS servers used across the Internet. The server can act as an authoritative, recursive, and caching name server and it supports wide range of features.

This tutorial will describe deploying primary and secondary BIND servers as authoritative name servers. This is suitable for public or private name servers, however, internal private name servers will usually include recursive and caching elements for local DNS resolution.

It is highly recommend that primary and secondary name servers are deployed on separate networks and in separate physical locations. This allows the necessary redundancy should one name server become unavailable due to server, network, or data centers failures.

Requirements

• Two servers (primary and secondary)
• Ubuntu 14.04 (Trusty Tahr)
• BIND 9
• Example domain: example.com
• Primary IP address: 192.0.2.1
• Secondary IP address: 192.0.2.2

Prepare Servers

Both network and host firewalls must allow incoming TCP and UDP traffic over port 53. Standard DNS requests occur over UDP port 53. However, if the response size is over 512 bytes, as the case may be with DNSSEC, the request will need to be sent over TCP port 53.

Zone transfers between the primary and secondary name servers will occur over TCP port 53.

ufw allow 53/udp
ufw allow 53/tcp

Install BIND

BIND is available from the default Ubuntu software repository. The bind-utils is extremely useful for testing and troubleshooting DNS related issues.

apt-get -y install dnsutils bind9

Configure Primary Server

The first step is to modify the named.conf.options file which usually preconfigured as a caching only name server.

nano /etc/bind/named.conf.options

The name server will need to respond to all incoming queries for authoritative zones, but should not allow zone transfer requests by default nor allow recursive queries.

Note: If these name servers on within a private network that will provide internal recursive DNS resolution along with authoritative DNS services, then recursion can be set to yes;. Otherwise, set to no;.

...
 allow-query { any; };
 allow-transfer { none; };
 recursion no;
 ...

Here is the full named.conf.options file example adjusted for authoritative name services. Comments have been removed for brevity.

options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
allow-query { any; };
allow-transfer { none; };
recursion no;
};

The path to the zone files and the zone details must be added to the /etc/bind/named.conf.local file.

nano /etc/bind/named.conf.local

The domain name section will be declared long with the path to the file containing the zone information, that this is the master zone, and the IP address of the secondary server.

zone "example.com" IN {
 type master;
 file "/var/lib/bind/db.example.com";
 allow-transfer { 192.0.2.2; };
 };

Save and close the file.

Create Zone File

The actual zone file can now be created.

nano /var/lib/bind/db.example.com

The zone file will contain domain settings and any resource records. Here is an example of a domain with a variety of resource records.

$TTL 3H
@ IN SOA @ hostmaster.example.com. (
0 ; serial
3H ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 192.0.2.10
@ IN MX 10 host2.example.com.
@ IN MX 20 host3.example.com.
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
host1 IN A 192.0.2.10
host2 IN A 192.0.2.11
host3 IN A 192.0.2.12
www IN CNAME example.com.
mail IN CNAME host2.example.com.
gopher IN CNAME host3.example.com.
example.com. IN TXT "v=spf1 ip4:203.0.113.42 include:_spf.google.com ~all"

The @ within the zone file presents the domain name itself. In this particular case, @ is equivalent to example.com. with the trailing period. A trailing period (.) is used to identify the end of the domain name within the zone file.

Save the zone file and exit the editor. You should confirm there are no errors in the configuration files before attempting to restart the service.

named-checkconf

The BIND named can now be restarted.

/etc/init.d/named restart

Configure Secondary Server

Log into the secondary server and modify the /etc/bind/named.conf.options file to match that of the primary server.

nano /etc/bind/named.conf.options

Refer to the Configure Primary Server section for the named.conf.options. Once the file has been updated, the zone needs to be added to /etc/bind/named.conf.local on the secondary server.

zone "example.com" IN {
type slave;
file "/var/cache/bind/db.example.com";
masters { 192.0.2.1; };
};

Save the zone file and exit the editor. You should confirm there are no errors in the configuration files before attempting to restart the service.

named-checkconf

The secondary named process can now be restarted.

/etc/init.d/named restart

Test DNS Resolution

The following dig command can be run from either name server should return the records for the domain on that server.

dig any example.com @localhost

You should also confirm results can be retrieved from a remote host that is able to connect to the name servers. This will confirm connectivity and that proper firewall rules are in place.

dig any example.com @192.0.2.1
dig any example.com @192.0.2.2

Modify Zone File

Zone files can be modified on the primary name servers. Once resource records have been added, modified, or removed, you must remember to increment the zone serial number. Here is the existing serial number of the example.com zone.

...
@ IN SOA @ hostmaster.example.com. (
0 ; serial
3H ; refresh
...

If the initial serial number begins at 0, then the next value will be 1.

...
@ IN SOA @ hostmaster.example.com. (
1 ; serial
3H ; refresh
...

Once the zone serial number has been incremented, the zone needs to be reloaded. This can be done without restarting the named process.

rndc reload example.com

The reload will also initiate a zone transfer to the secondary server.

Reverse DNS

Reverse DNS is the mapping of an IP address to a domain name rather than a domain name to an IP address. Some services, such as SMTP or Kerberos, may require proper reverse resolution.

In most cases regarding the public IP address space, reverse DNS will be handled by the service provider managing the IP subnets. It is suggested that you contact the support department of the service provider if you require adjustments to the reverse DNS.

There may be situations where the reverse DNS for a subnet has been delegated to your name servers. Or perhaps you wish to assign reverse DNS records to a private, internal network. In these situations, a special domain named in-addr.arpa is used with a reverse representation of the IP range.

The zone file for the 192.0.2.0/24 subnet would be 2.0.192.in-addr.arpa and would follow the same configuration process as a normal zone file on the primary and secondary name servers.

Once the zone has to been added to the primary and secondary named.rfc1912.zones files, the zone can be created.

nano /var/lib/bind/2.0.192.in-addr.arpa

Here is an example of the PTR records in the 2.0.192.in-addr.arpa zone file.

$TTL 3H
@ IN SOA @ hostmaster.example.com. (
2 ; serial
3H ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
10 IN PTR host1.example.com.
11 IN PTR host2.example.com.
12 IN PTR host3.example.com.

Troubleshoot DNS Issues

Syntax errors in the configuration files are easy to overlook. Therefore, it is always recommended to run named-checkconf before starting or restarting the named process.

named-checkconf

When problems occur, the named log file is the first place to start looking. The log file on Ubuntu is written to the syslog file.

/var/log/syslog

The dnsutils includes several utilities such as dig, nslookup, and host. These can be used to verify queries directly against the authoritative name servers. They will require the domain name, the authoritative server, and optionally a resource record as parameters.

dig mx example.com @192.0.2.1

A query against the authoritative name server will display the current zone and resource records regardless of caching or TTL.

One last tip for troubleshooting registered domains over the public Internet is to verify the domain registrar is aware of the authoritative name servers and that the domain name has not expired.

whois example.com

If whois is not aware of the top level domain, as new TLDs are being frequently released, then you may need to perform the whois search from the central registry for domains under the desired TLD.

source (1) profitbricks.com