Configure Authoritative Name Server Using BIND on CentOS 6

Table of Contents


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.


  • Two servers (primary and secondary)
  • CentOS or Red Hat Enterprise Linux 6
  • BIND 9
  • Example domain: example.com
  • Primary IP address:
  • Secondary IP address:

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.

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT
iptables -A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT
service iptables save

Install BIND

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

yum -y install bind bind-utils

Configure Primary Server

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

nano /etc/named.conf

In order for the name server to respond to external requests, the named process will need to be bound to a public IP address. The any value will bind to all IP addresses assigned to the server.

listen-on port 53 { any; };
listen-on-v6 port 53 { any; };

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 file example adjusted for authoritative name services.

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    directory       "/var/named";
    dump-file       "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query     { any; };
    allow-transfer  { none; };
    recursion no;

    dnssec-enable yes;
    dnssec-validation yes;
    dnssec-lookaside auto;

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";

logging {
    channel default_debug {
        file "data/named.run";
        severity dynamic;

zone "." IN {
    type hint;
    file "named.ca";

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

The path to the zone files and the zone details must be added to the /etc/named.rfc1912.zones file.

nano /etc/named.rfc1912.zones

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 "example.com";
    allow-transfer {; };

Save and close the file.

Create Zone File

The actual zone file can now be created.

nano /var/named/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.

@   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
@            IN   MX     10 host2.example.com.
@            IN   MX     20 host3.example.com.
ns1          IN   A
ns2          IN   A
host1        IN   A
host2        IN   A
host3        IN   A
www          IN   CNAME  example.com.
mail         IN   CNAME  host2.example.com.
gopher       IN   CNAME  host3.example.com.
example.com. IN   TXT    "v=spf1 ip4: 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 named.conf file before attempting to start the service.


The BIND named can now be enabled on boot and started.

chkconfig named on
/etc/init.d/named start

Configure Secondary Server

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

nano /etc/named.conf

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

zone "example.com" IN {
    type slave;
    file "slaves/example.com";
    masters {; };

Save the zone file and exit the editor. You should confirm there are no errors in the named.conf file before attempting to start the service.


The secondary named process can now be enabled on boot and started.

chkconfig named on
/etc/init.d/named start

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 @
dig any example.com @

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 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/named/2.0.192.in-addr.arpa

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

@   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.


When problems occur, the named log file is the first place to start looking. The log file on CentOS will be found here:


The bind-utils 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 @

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.