Nameserver Basics: What is an Authoritative Server? What is a Recursive Server?
On occasion, when a security defect is found in BIND, ISC issues a security advisory. Sometimes the "Impact" section of these advisories contains a qualification as to what kind of nameserver is affected by the defect, i.e. if the bug is known to affect only authoritative nameservers or only recursive nameservers. But what do these categories mean?
Nameserver functionality can be divided into two main categories: authoritative service and recursive service. BIND can be configured by the administrator to be an authoritative nameserver, a recursive nameserver, or both. (It could also be configured to be neither, but there would be no reason to run such a server, as it would be unable to provide any answers in response to queries.)
An authoritative nameserver is one that is configured to answer queries for a specified set of zones and satisfies queries from its own data without needing to reference another source. If it is only authoritative, and not also configured to act as a recursive nameserver, it will usually respond to queries with one of the following types of answers:
- authoritative data from its own store (which can come from a zone master file, from a copy of that data transferred from a master server, from a database, from dynamic DNS, be built in, etc.)
- if it does not know the answer, a referral to another nameserver (i.e. "I don't know that answer, but you can talk to server so-and-so, which answers questions for this subdomain")
- an authoritative NXDOMAIN (where it can respond authoritatively that the name requested does not exist)
- an authoritative empty NOERROR answer (also known as NODATA, where the name requested does exist, but the resource record type being queried does not)
For example, an authoritative server may respond with SERVFAIL or REFUSED in situations where there is a problem with configuration or delegation.
A nameserver is usually configured to perform authoritative service for a fixed set of zones, which are declared in the named.conf file using the "zone" statement with zone type master or slave. Recent versions of BIND also support adding and removing zones dynamically via rndc. A typical use case for an authoritative name server would be to serve your own zones to the world.
A recursive nameserver is one that answers queries by asking other nameservers for the answer. It will satisfy queries from cache if possible, but otherwise it traverses the Internet (or private) namespace tree, from the root level if necessary, repeatedly asking the query on behalf of its client and following referrals from authoritative servers until it finds one that provides the answer(s) that it can return to its client.
A typical use case for a recursive server is to satisfy client machine queries for resource records in any zone.
Recursive nameservers are sometimes referred to as 'caching nameservers' or 'caches' because under normal operation recursive nameservers will store in memory the responses received from other servers and reuse them in order to reduce network traffic and to improve performance. In most cases, servers referred to in this way are not authoritative for any zones other than the standard minimal ones containing local host names and addresses and the recommended empty zones. However, recursive nameservers can be configured to serve zones authoritatively. This is sometimes done to block client queries to undesirable domains, either with manually administered zones that return locally configured responses for those domains, or by using DNS RPZ.
Recursive nameservers generally respond to queries with the following:
- authoritative data from its own store, if any (this may include either positive responses or NXDOMAIN or NOERROR/NODATA)
- non-authoritative data that has been cached as a result of a prior recursive query, if any
- data retrieved from remote authoritative name servers, which can then be cached and reused in response to future queries.
A typical use case for a recursive nameserver would be to answer general DNS queries for clients on your local network.
The BIND configuration option recursion yes|no; controls whether or not clients are permitted to make recursive queries and the "allow-recursion" option controls which clients are permitted this privilege. For more details, and for other options that provide finer-grained control to nameserver functionality, see the Administrator Reference Manual (ARM) which is delivered with the BIND source code and is also available online.
This refers to the way that the authoritative servers in the DNS namespace are 'found' by recursive servers. Delegation is what happens when the administrators for a parent domain (e.g. test.com provides within its zone the details of the nameservers for mytest.test.com - although this doesn't mean that the servers so named can actually answer any queries for names in mytest.test.com). Having a zone delegated to your server doesn't (by itself) make it an authoritative server - it also needs to be configured to serve that zone.
Conversely, people sometimes are confused into thinking that their servers are not authoritative because there is no delegation to them. However, there is nothing preventing a nameserver operator from configuring their server to provide an authoritative answer for a zone for which they have not been delegated authority, and many operators choose to do this for a variety of reasons. Those servers are performing an authoritative function.
Primary and Secondary Servers
Secondary servers, even though they receive a copy of their zone data from a primary server, still answer queries authoritatively from locally stored zone data and not by recursing. Secondary servers are authoritative servers for the zones they are publishing.