In Linux you use the configuration files and options to do most things in system and system services. But to do everything correct, you must know What you are doing. After playing with BIND and PowerDNS, I understood how important it is to know some DNS theory. Here is one of the most important pieces of theory for me – DNS Types with explanations:

Master (Primary) Name Servers 

A master DNS configuration, also known as a zone master configuration, contains one or more zone files for which this DNS is authoritative and that it reads from a local file system. The term master is related to the location of the zone file rather than any other operational characteristics. A master may be requested to transfer zone files—using zone transfer operations to one or more slave servers whenever the zone file changes. 

A zone master obtains the zone data from a local zone file as opposed to a zone slave, which obtains its zone data via a zone transfer operation from the zone master. This seemingly trivial point means that it is possible to have any number of zone masters for any zone if that makes operational sense. Zone file changes need to be synchronized between zone masters by a manual or automated process. This may be easier to manage than securing the zone transfer operations inherent in a master-slave configuration.

The term primary master has crept into the jargon; it has a special meaning only in the context of dynamic DNS (DDNS) updates and is defined to be the name server that appears in the SOA resource record. 

A master name server can indicate (using NOTIFY messages) zone changes to slave servers. This ensures that zone changes are rapidly propagated to the slaves rather than simply waiting for the slave to poll for changes at each SOA RR refresh interval.  

Slave servers will respond as authoritative to queries for the domain as long asthey hold valid zone records. This feature provides the user with a lot of flexibility when registering name servers for a given domain. When registering such name servers, the only requirement is that the servers listed will respond as authoritative to queries for the domain or zone. It is not necessary to define the zone master as one of these name servers; two or more slave servers will satisfy the requirement. This flexibility allows the zone master to be hidden from public access if required (a.k.a. a hidden master).

Slave (Secondary) Name Servers 

A slave name server obtains its zone information from a zone master, but it will respond as authoritative for those zones for which it is defined to be a slave and for which it has valid zone records (the zone records have not expired). The act of transferring the zone may be viewed as having delegated authority for the zone to the slave for the time period defined in the expiry value of the SOA record  and thus enables the slave to respond authoritatively to queries. 

A slave server attempts to update the zone records when the refresh parameter of the SOA RR is reached. If a failure occurs, the slave will periodically try to reach the zone master(s) every retry period. If a slave has still not reached the master DNS when the expiry time of the SOA RR for the zone has been reached, it will stop responding to queries for the zone. The slave will not use time-expired data.

A zone slave obtains all the zone data for which it is acting as a slave via zone transfer operations. This process should not be confused with a cache. The slave server uses the refresh and expiry values from the SOA RR to time-out its zone data and then retransfers all the zone data. A cache, on the other hand, contains individual RRs obtained in response to a specific query originating from a resolver or another name server acting on behalf of a resolver and discards each RR when its TTL is reached. In addition, a slave server always responds authoritatively to requests for information about its zone. A cache will only respond authoritatively with zone data the first time it obtains the data (directly from the zone’s masteror slave). Thereafter, when reading from its cache, the data is not marked as authoritative.

Caching Name Servers 

A caching name server (a.k.a. caching resolver, DNS cache, or, most commonly, resolver) obtains specific information in the form of one or more resource records about a domain by querying a zone’s authoritative name server (master or slave) in order to answer a host/client query and subsequently saves (caches) the data locally. On a subsequent request for the same data, the caching server will respond with its locally stored data from the cache. This process will continue until the Time to Live (TTL) value of the RR expires, at which time the RR will be discarded from the cache. The next request for this RR will result in the resolver again querying an authoritative name server for the zone. Caches considerably increase DNS performance for local PCs or hosts and can also significantly reduce network loads by obtaining a single copy of frequently accessed data and making it available many times with no additional overhead.

If the resolver obtains its data directly from an authoritative DNS, then it too will respond as authoritative. Otherwise, if the data is supplied from its cache, the response is nonauthoritative.

Caching Implications 

To cache or not to cache is a crucial question in the world of DNS, since it incurs substantial performance overheads. Also, because it interfaces with the external network, you run the risk of cache poisoning or corruption through malicious attacks. This downside must be offset against the significant performance gains that are obtained when using a resolver. The most common uses of DNS caching configurations are as follows:

  • As a name server acting as master or slave for one or more zones (domains) and as a caching server for all other queries. A general-purpose name server.
  • As a caching-only name server (resolver)—typically used to support standard PCbased resolvers (stub resolvers), which require recursive query support that is only provided by a caching name server. One or more caching-only servers are typically present in networks such as ISPs or large organization networks. The term area resolver is frequently used to describe caching-only name servers in larger networks since they tend to be provisioned on a geographic basic.

However, if a general-purpose name server is being hit thousands of times per second in support of a high-volume site, performance becomes a major factor; in this case, caching would typically be disabled. Furthermore, there are many DNS administrators who, due to the cache-related dangers described previously, will never allow caching behavior on a name server that has any master or slave zones.

Forwarding (Proxy) Name Servers 

A forwarding (a.k.a. proxy, client, or remote) DNS server is one that forwards all queries to another DNS and caches the results. On its face, this looks to be a pretty pointless exercise. However, a forwarding name server can pay off in the following ways when access to an external network is slow, expensive, or heavily congested:

  • The name server to which queries are forwarded will provide recursive query support resulting in a single query-answer DNS transaction. If the local name server were a caching-only server and did not forward queries, multiple transactions would occur, thus increasing network load and time delays.
  • The local or on-site forwarding DNS server will cache results and thereby provide both faster responses for frequently accessed information and eliminate unnecessary (and potentially risky) external traffic.

Forwarding name servers can also be used tactically to ease the burden of local administration. Each PC may be defined to use a local forwarding name server, which in turn is defined to pass all queries to an external server. If the external DNS server changes when the user changes ISP, for example, a single configuration change to the local name server’s named.conf file is all that is required, instead of having to change all the local PC configurations.

Forwarding may also be used as part of a stealth (or split) server configuration for perimeter defense.

Stealth (DMZ or Split) Name Server 

A stealth server is defined as a name server that does not appear in any publicly visible NS RRs for the domain. Stealth servers are used in configurations that are sometimes called demilitarized zones (DMZs) or split servers and can be defined as having the following characteristics:

  • The organization needs to expose DNS servers to provide access to its public services such as web sites, e-mail, FTP sites, and so forth.
  • The organization does not want the world to see any of its internal hosts either by interrogation (query or zone transfer) or in the event the DNS service or external servers are compromised.

The external or public servers are configured to provide authoritative-only responses and nocaching services—recursive queries are not accepted. In this case, caching is both wasteful in terms of performance and a possible source of pollution or corruption, both of which can lead to system compromise. The internal name server—the stealth server—zone file will make visible internal and external hosts, provide recursive queries, and all manner of other services.

Authoritative-only Name Server 

The term authoritative-only name server is normally used to describe two related properties of a DNS server:

  • The name server will deliver authoritative answers; it is a zone master or slave for one or more domains.
  • The name server does not cache.

Authoritative-only servers are typically used in two distinct configurations:

  • As public or external servers in a stealth DNS configuration used to provide perimeter security.
  • As high-performance name servers, for example, root-servers, TLD servers, or name servers for high-volume sites.

Authoritative-only servers typically have high performance requirements.