Actions: | Security

Navigation: Home | Services | Tools | Articles | Other

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.

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,

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;;};
        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 zone based on the data in /var/named/

view    "external"
/* This view will contain zones you want to serve only to "external" clients
 * that have addresses that are not on your directly attached LAN interface subnets:
        match-clients           { any; };
        match-destinations      { any; };

        recursion no;

        // These are your "authoritative" external zones
        zone "" {
                type master;
                file "";

        // Reverse
            zone "0.168.192.IN-ADDR.ARPA" {
                    type master;
                    file "";


Secondaries and Transfers

Secondary or backup name service allows a zone admin to configure multiple machines to answer requests based on automated replication of the zone information using transfers.

Configuring a primary machine to permit a transfer

A new Access Control List(ACL) stanza must be added to named.conf:

acl secondaries {
    // IP addresses for any secondary servers;;

The zone stanza must be modified as well:

zone "" {
         type master;
         file "";
         allow-transfer {
Configuring a secondary machine to receive a transfer

A zone stanza must be inserted for each zone you want to be a secondary for:

zone "" {
         type slave;
         file "";
         masters {
                 // IP addresses of one or more masters

Checking it works

Use named-checkconf(8) and/or named-checkzone(8) to verify that your configs are valid.

The most common mistake when modifying a zone file is to forget to update the serial number.

Don't forget to configure both forward and reverse zones.

Example Zone Files

At a basic level, zone files are fairly straightforward to understand if you keep the following definitions in mind:

A records
the basic DNS record that translates names to IP addresses
consider this to be an aliasing of one name to another name
Mail eXchanger. These records list which hosts handle mail for the zone
Name Server. These records list which hosts are authoritative DNS servers for the zone
PoinTeR records handle reverse resolution, that is mapping addresses to names

Consider using nslint(8) to check on your DNS config; it's likely available in your distro's package archive.

Forward        IN SOA (
                        2011100301                   ;Serial
                        1h                           ;Refresh
                        1h                           ;Retry
                        1w                           ;Expire
                        1h                           ;Negative caching TTL

;name servers                IN NS

;A records
gw                              IN A
ns1                             IN A
smtp                            IN A
imap                            IN A
www                             IN A

;CNAME records
mirror                          IN CNAME www

;MX records                        IN MX 10        mail

A reverse zone file for might look like this:

@ IN SOA (
        2011100301     ; Serial
        1h                           ;Refresh
        1h                           ;Retry
        1w                           ;Expire
        1h                           ;Negative caching TTL


1               IN PTR gw
2               IN PTR ns1
3               IN PTR smtp
4               IN PTR imap
5               IN PTR www