4. DNS Configuration Types

Most DNS servers are schizophrenic - they may be masters (authoritative) for some zones, slaves for others and provide caching or forwarding for all others. Many observers object to the concept of DNS types partly because of the schizophrenic behaviour of most DNS servers and partly to avoid confusion with the name.conf zone parameter 'type' which only allows master, slave, stub, forward, hint). Nevertheless, the following terms are commonly used to describe the primary function or requirement of DNS servers.

Note: Running any DNS server that does not require to support recursive queries for external users (an Open DNS) is a bad idea. While it may look like a friendly and neighbourly thing to do it carries with it a possible threat from DoS attacks and an increased risk of cache poisoning. The various configurations have been modified to reflect this.

A Master DNS contains one or more zone files for which this DNS is Authoritative ('type master'). The zone has been delegated (via an NS Resource Record) to this DNS.

The term 'master' was introduced in BIND 8.x and replaced the term 'primary'.

Master status is defined in BIND by including 'type master' in the zone declaration section of the named.conf file) as shown by the following fragment.

// example.com fragment from named.conf 
// defines this server as a zone master
zone "example.com" in{
	type master;
	file "pri.example.com";
};

Notes:

1. The terms Primary and Secondary DNS entries in Windows TCP/IP network properties mean nothing, they may reflect the 'master' and 'slave' name-server or they may not - you decide this based on operational need, not BIND configuration.

2. It is important to understand that a zone 'master' is a server which gets its zone data from a local source as opposed to a 'slave' which gets its zone data from an external (networked) source (the 'master'). This apparently trivial point means that you can have any number of 'master' servers for any zone if it makes operational sense. You have to ensure (by a manual or other process) that the zone files are synchronised but apart from this there is nothing to prevent it.

3. Just to confuse things still further you may run across the term 'Primary Master' this has a special meaning in the context of dynamic DNS updates and is defined to be the name server that appears in the SOA RR record.

When a master DNS receives Queries for a zone for which it is authoritative then it will respond as 'Authoritative' (AA bit is set in a query response).

When a DNS server receives a query for a zone which it is neither a Master nor a Slave then it will act as configured (in BIND this behaviour is defined in the named.conf file):

1. If caching behaviour is permitted and recursive queries are allowed the server will completely answer the request or return an error.
2. If caching behaviour is permitted and Iterative (non-recursive) queries are allowed the server can respond with the complete answer (if it is already in the cache because of another request), a referral or return an error.
3. If caching behaviour NOT permitted (an 'Authoritative Only' DNS server) the server will return a referral or return an error.

A master DNS server can export (NOTIFY) zone changes to defined (typically slave) servers. This ensures zone changes are rapidly propagated to the slaves (interrupt driven) rather than rely on the slave server polling for changes. The BIND default is to notify the servers defined in NS records for the zone.

If you are running Stealth Servers and wish them to be notified you will have to add an also-notify parameter as shown in the BIND named.conf file fragment below:

// example.com fragment from named.conf 
// defines this server as a zone master
// 192.168.0.2 is a stealth server NOT listed in a NS record
zone "example.com" in{
	type master;
	also-notify {192.168.0.2;};
	file "pri/pri.example.com";
};

You can turn off all NOTIFY operations by specifying 'notify no' in the zone declaration.

Example configuration files for a master DNS are provided.

A Slave DNS gets its zone file information from a zone master and it will respond as authoritative for those zones for which it is defined to be a 'slave' and for which it has a currently valid zone configuration.

The term 'slave' was introduced in BIND 8.x and replaced the term 'secondary'.

Slave status is defined in BIND by including 'type slave' in the zone declaration section of the named.conf file) as shown by the following fragment.

// example.com fragment from named.conf 
// defines this server as a zone slave
zone "example.com" in{
	type slave;
	file "sec/sec.example.com";
	masters {192.168.23.17;};
};

Notes:

1. The master DNS for each zone is defined in the 'masters' zone section and allows slaves to refresh their zone record when the 'expiry' parameter of the SOA Record is reached. If a slave cannot reach the master DNS when the 'expiry' time has been reached it will stop responding to requests for the zone. It will NOT use time-expired data.
2. The file parameter is optional and allows the slave to write the transferred zone to disc and hence if BIND is restarted before the 'expiry' time the server will use the saved data. In large DNS systems this can save a considerable amount of network traffic.

Assuming NOTIFY is allowed in the master DNS for the zone (the default behaviour) then zone changes are propagated to all the slave servers defined with NS Records in the master zone file. There can be any number of slave DNS's for any given 'master' zone. The NOTIFY process is open to abuse. BIND's default behaviour is to only allow NOTIFY from the 'master' DNS. Other acceptable NOTIFY sources can be defined using the allow-notify parameter in named.conf.

Example configuration files for a slave DNS are provided.

A Caching Server obtains information from another server (a Zone Master) in response to a host query and then saves (caches) the data locally. On a second or subsequent request for the same data the Caching Server will respond with its locally stored data (the cache) until the time-to-live (TTL) value of the response expires at which time the server will refresh the data from the zone master.

If the caching server obtains its data directly from a zone master it will respond as 'authoritative', if the data is supplied from its cache the response is 'non-authoritative'.

The default BIND behaviour is to cache and this is associated with the recursion parameter (the default is 'recursion yes'). There are many configuration examples which show caching behaviour being defined using a type hint statement in a zone declaration. These configurations confuse two distinct but related functions. If a server is going to provide caching services then it must provide recursive queries and recursive queries need access to the root servers which is provided via the 'type hint' statement. A caching server will typically have a named.conf file which includes the following fragment:

// options section fragment of named.conf 
// recursion yes is the default and may be omitted
options {
	directory "/var/named";
	version "not currently available";
	recursion yes;
};
// zone section
....
// the DOT indicates the root domain = all domains
zone "." IN {
	type hint;
	file "root.servers";
};

Notes:

1. BIND defaults to recursive queries which by definition provides caching behaviour. The named.conf recursion parameter controls this behaviour.
2. The zone '.' is shorthand for the root domain which translates to 'any domain not defined as either a master or slave in this named.conf file'.
3. cache data is discarded when BIND is restarted.

The most common DNS server caching configurations are:

• A DNS server acting as master or slave for one or more zones (domains) and as cache server for all other requests. A general purpose DNS server.
• A caching only local server - typically used to minimise external access or to compensate for slow external links. This is sometimes called a Proxy server though we prefer to associate the term with a Forwarding server

To cache or not is a crucial question in the world of DNS. BIND is regarded as the reference implementation of the DNS specification. As such it provides excellent - if complex to configure - functionality. The down side of generality is suboptimal performance on any single function - in particular caching involves a non-trivial performance overhead.

For general usage the breadth of BIND functionality typically offsets any performance concerns. However if the DNS is being 'hit' thousands of times per second performance is a major factor. There are now a number of alternate Open Source DNS servers some of which stress performance. These servers typically do NOT provide caching services (they are said to be 'Authoritative only' servers).

Example configuration files for a caching DNS are provided.

Note: The response to a query is Authoritative under three conditions:

1. The response is received from a Zone master.
2. The response is received from a Zone slave with non time-expired zone data.
3. The response is received by a caching server directly from either a Zone master or slave. If the response is read from the cache directly it is not authoritative.

A stealth server is defined as being a name server which does not appear in any publicly visible NS Records for the domain. The stealth server is normally used in a configuration called Split Severs which can be roughly defined as having the following characteristics:

1. The organisation needs a public DNS to enable access to its public services e.g. web, mail ftp etc..
2. The organisation does not want the world to see any of its internal hosts either by interrogation (query or zone transfer) or should the DNS service be compromised.

A Split Server configuration is shown in Figure 4.1.

Figure 4.1 Split Server configuration

The external server(s) is(are) configured to provide Authoritative Only responses and no caching (no recursive queries accepted). The zone file for this server would be unique and would contain ONLY those systems or services that are publicly visible e.g. SOA, NS records for the public (not stealth) name servers, MX record(s) for mail servers and www and ftp service A records. Zone transfers can be allowed between between the public servers as required but they MUST NOT transfer or accept transfers from the Stealth server. While this may seem to create more work, the concern is that should the host running the external service be compromised then inspection of the named.conf or zone files must provide no more information than is already publically visible. If 'master', 'allow-notify','allow-transfer' options are present in named.conf (each of which will contain a private IP) then the attacker has gained more knowledge about the organisation - they have penetrated the 'veil of privacy'.

There are a number of articles which suggest that the view statement may be used to provide similar functionality using a single server but this does not address the problem of the DNS host system being compromised and by simple inspection of the named.conf file additional data about the organisation could be discovered. In our opinion 'view' does not provide adequate security in a 'Split DNS' solution.

A minimal public zone file is shown below:

; public zone master file
; provides minimal public visibility of external services
example.com.  IN      SOA   ns.example.com. root.example.com. (
                              2003080800 ; se = serial number
                              3h         ; ref = refresh
                              15m        ; ret = update retry
                              3w         ; ex = expiry
                              3h      ; min = minimum
                              )
              IN      NS      ns1.example.com.
              IN      NS      ns2.example.com.
              IN      MX  10  mail.example.com.
ns1           IN      A       192.168.254.1
ns2           IN      A       192.168.254.2
mail          IN      A       192.168.254.3
www           IN      A       192.168.254.4
ftp           IN      A       192.168.254.5

The internal server (the Stealth Server) can be configured to make visible internal and external services, provide recursive queries and all manner of other services. This server would use a private zone master file which could look like this:

; private zone master file used by stealth server(s)
; provides public and private services and hosts
example.com.  IN      SOA   ns.example.com. root.example.com. (
                              2003080800 ; se = serial number
                              3h         ; ref = refresh
                              15m        ; ret = update retry
                              3w         ; ex = expiry
                              3h         ; min = minimum
                              )
              IN      NS      ns1.example.com.
              IN      NS      ns2.example.com.
              IN      MX  10  mail.example.com.
; public hosts
ns1           IN      A       192.168.254.1
ns2           IN      A       192.168.254.2
mail          IN      A       192.168.254.3
www           IN      A       192.168.254.4
ftp           IN      A       192.168.254.5
; private hosts 
joe           IN      A       192.168.254.6
bill          IN      A       192.168.254.7
fred          IN      A       192.168.254.8
....
accounting    IN      A       192.168.254.28
payroll       IN      A       192.168.254.29

Using BIND 9's view statement can provide different services to internal and external requests can reduce further the Stealth server's visibility e.g. forwarding all DNS internal requests to the external server.

Example configuration files for a stealth DNS are provided.