Configuring the BIND Linux DNS Server

The BIND DNS server is by far the most widely used DNS server on the Internet and is overwhelmingly the most commonly used DNS server software on Linux servers. Your Linux DNS server can be configured to perform a number of different roles to suit your requirements and the majority of this configuration is performed in the named.conf file or files included in the DNS servers configuration by statements within named.conf. There are additional files that are referenced to provide additional information about root nameservers and zones that the DNS server is authoritive for and these are usually stored in the DNS servers working directory.

Your DNS server may be configured to be an authoritative name server which contains the complete data for a particular zone or collection of zones within a domain. Authoritative name servers can be classified as a primary master, secondary (slave) server or stealth server. Or you may require a caching name server that performs recursive lookups for domains that it is not authoritive for and cache the results to reduce DNS traffic. Or you may elect to have a forwarding name server which may consult several other name servers before performing a recursive lookup. BIND can perform some or even all of these roles simultaneously.

Authoritative Name Servers Each zone configured on your DNS service must be served by at least one authoritative name server which contains the complete data for the zone. It is considered best practice to have at least two authoritative name servers on two different networks preferably in two seperate geographic locations for the purposes of redundancy. You can have your authoritative name servers in one location on the same network and your DNS service will still work, however you are more susceptable to outages due to network failures, power failures and the like. Of your authoritative name servers one should be configured as a primary master DNS server and the others should be configured as slave servers. Often slave servers are also referred to as secondary DNS servers.

The Primary Master DNS Server is the authoritative name server where the master copy of the zone data is maintained. The data is stored in a local file or database called a zone file and it is this information that is edited by the Linux server administrator when information about the DNS zone needs to be added, removed or changed. The primary master DNS server will usually be configured to update the slave servers when the zone is reloaded so that they maintain current records for the zone and the records stored on all of your authoritative name servers match.

Slave or Secondary DNS servers load the data of the zone from the primary master server through a process called a zone transfer. A zone transfer takes place automatically at set intervals or when the primary master server is told to reload a zone using the rndc reload command. The primary master simply sends the slave server(s) the information stored in the relevant zone file and the slave server will acknowledge its receipt, discard the old information and start using the new data.

Stealth Name Servers are name servers that are not listed in the name servers of the parent zone but are they listed in the zone file itself and are kept updated as a result of this by zone transfers from the primary master. They are useful for keeping a local copy of a zone to speed up access to a zones records or to ensure a zone is available locally if all of the authoritative name servers listed at the parent name servers are unavailable.

Caching Name Servers

Caching Name Servers are often referred to as recursive name servers as they perform recursive lookups on behalf on local client computers that are unable to do so. The resolver libraries provided by most operating systems are stub resolvers, meaning that they are unable to perform the full DNS resolution process and need a name server to perform the task for them. To improve performance, once a lookup has been performed a caching name server will then store the results in its cache and supply this answer if the same lookup is requested again. The length of time the response is cached is dependant on the TTL (time to live) field specified in the zones zone file.

Forwarding can reduce lookup times and DNS traffic. If a caching name server cannot satisfy a query by an answer stored in its own cache it may forward the request to other caching name servers first before performing a recursive lookup. These other caching name servers are referred to as forwarders and there may be several specified in your name servers configuration. It is not uncommon to forward queries to your wholesalers or ISP's name servers.