AllGoodBits.org

DNS Service

Setting up a small DNS server is a fairly straightforward, common task for a network administrator or system administrator in a small to medium sized environment. There is a fair amount of jargon involved and some common usage is unnecessary confusing. I'll try to elucidate a few key concepts and demonstrate some important configuration items. I'm using BIND, the most common nameserver daemon.

Authoritative nameservers

Authoritative name service provides data about a zone from the administrators of that zone or from their delegates. In other words, if you run a zone then the zone files that describe that zone are used to answer requests authoritatively, in contrast to a caching resolver which will discover the answers to DNS requests about zones that you do not control. A primary authoritative nameserver will usually notify any secondary nameservers when the zone is updated and the new data will be transferred so that the secondary nameserver(s) remain current.

Caching resolvers

Caching/resolving dns servers provide resolution for your clients. They mean that many resolution requests can be handled without sending packets of the local network. When a client makes a dns request, the cache replies if it can or if not, it finds the answer, caches it for next time (subject to timeouts) and informs the originating client. Also referred to as a recursive resolver because they have to ask someone else for the answers.

they should be separated from authoritative servers that provide information about zones that you control to the world in general. This separation ideally should be separate machines with separate IP addresses.

recursive services should only be offered to your own clients not to the internet as a whole.

Split DNS

The term 'Split DNS' refers to the practice of providing different answers to dns resolution queries depending on who is asking. Generally, this is manifested as giving the internet at large a different, reduced view of your organisation's dns information. For example, if you have a database server for internal usage only that does not accept connections from outside your network, why should you publish dns information for it? In particular, you should not publish dns information to the outside world for hosts in private network address space. In BIND9, this is configured using a 'view' block.

Practical configuration for BIND9

Basic caching resolver

The following named.conf creates a caching resolver for use by the local subnet, 192.168.0.0/16.

options {
directory "/var/named"; // the default
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";
};
view "localhost_resolver"
{
/* This view sets up named to be a localhost resolver ( caching only nameserver ).
* If all you want is a caching-only nameserver, then you need only define this view:
*/
match-clients { localhost; 192.168.0.0/16;};
recursion yes;
# all views that allow recursive service must contain the root hints zone:
include "/etc/named.root.hints";
/* these are zones that contain definitions for all the localhost
* names and addresses, as recommended in RFC1912 - these names should
* ONLY be served to localhost clients:
*/
include "/etc/named.rfc1912.zones";
};

The files /etc/named.root.hints, /etc/named.rfc1912.zones and the files that they refer to come in the distribution.

Basic Authoritative Service

Appending the following fragment to named.conf will allow this host to serve the allgoodbits.org zone based on the data in /var/named/allgoodbits.org.db.