Named.conf for an Authoritative Name Server

An authoritative name server configuration includes specific zones for which it is authoritive. The named.conf for an authoritative name server does not differ a great deal from a caching name server named.conf. To avoid repetition on this web site we ask that you start with the basic configuration for a caching name server as described on Caching DNS Config taking specific care to include the named.local and localhost.zone files in your working directory. It is a good idea to include the named.root hint file as well although it is quite possible to turn caching and recursive queries off resulting in a nameserver that will only answer queries for zones that it is authoritative for.

Our example /etc/named.conf for an authoritative nameserver is shown below. Please bear in mind that anything to the right of a // is considered to be a comment and is ignored by named.

options {       // Configuration Options directory "/var/named";      // Working Directory }; // // zone "." IN {       // The file named.root is placed type hint;       // in the working directory file "named.root";       // and contains the IP addresses of the parent name servers }; zone "localhost" IN {       // This zone permits localhost to be resolved to 127.0.0.1 type master; file "localhost.zone"; allow-update { none; }; }; zone "0.0.127.in-addr.arpa" IN {       // This zone permits a reverse lookup on 127.0.0.1 to resolve to localhost type master; file "named.local"; allow-update { none; }; }; zone "example.com" IN {      // This is a zone for which this name server is primary master type master; file "example.com.zone"; }; zone "exampletoo.com" IN {      // This is a zone for which this name server is a slave type slave; file "exampletoo.com.bk"; masters { 192.168.203.26, }; };

Primary Name Server Configuration A primary name server or master name server holds the master copy of the data for a given dns zone. This master copy is usally kept in the form of a text file commonly called a zone file though there is a growing trend towards this information being stored in a variety of different database backends instead. To avoid confusion we shall focus on text zone files on this part of Linux Server How To's tutorials on using BIND. We can see in our example named.conf that our Linux DNS server is configured as a primary master for the domain example.com and as a slave for the domain exampletoo.com. It is very possible to mix and match functionality with the BIND DNS server and as a result a name server that is a primary master for some domains can also be a slave server for others.

In our example named.conf we can see the stanza that makes BIND aware that it is authoritative for the example.com domain. Zone specifies the particular DNS zone, in this instance example.com and type makes BIND aware that it is the primary master for the zone. File specifies the zone files name, which does not include the full path to the file as we have nominated the working directory earlier in named.conf in the options section at the beginning of the file.

zone "example.com" IN { type master; file "example.com.zone"; };

Our example.com zone file is as below. This can be considered a reasonably good example as it contains many common elements of a production zone file including Start of Authority Record, NS records, MX records and a number of A records and CNAME's for various hosts within the example.com zone. For a fuller explanation of the anatomy of a zone file please consider reading the Zone Files page of Linux Server How To.

@ IN SOA ns1.example.com. admin.example.com. ( 2009110101 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum ; ; IN NS ns1.example.com. IN NS ns2.example.com. ; ; IN MX 10 mail IN MX 20 mx2 ; ; localhost IN A 127.0.0.1 ; ; @ IN A 192.168.100.200 www IN A 192.168.100.200 mail IN A 192.168.100.201 pop IN CNAME mail smtp IN CNAME mail mx2 IN A 192.168.100.202 ns1 IN A 192.168.100.203 ns2 IN A 192.168.200.12 ;

Slave Name Server Configuration

A slave name server or secondary name server loads the zone file contents from another server, typically the primary master name server, through a replication process known as a zone transfer. This means that on each slave server there are no zone files to maintain as they are maintained and updated automatically. The slave server(s) simply need to know they are authoritative for the domain and the IP address of the name server they will transfer the zone from. This is achieved through named.conf.

zone "exampletoo.com" IN { type slave; file "exampletoo.com.bk"; masters { 192.168.203.26, }; };

We can see the stanza in named.conf for our fictitious domain exampletoo.com above. The zone statement specifies the zone as exampletoo.com. The type statement makes BIND aware that it is a slave for this domain and the file statement tells BIND to store the transfered zone in the file exampletoo.com.bk which it will create automatically in the working directory. Finally, the master is defined as 192.168.203.26 and this tells BIND where to transfer the zone from.