Named.conf

named.conf

Named.conf controls system-wide configuration of named (*nix's standard DNS server, the Berkeley Internet Name Daemon), and also tells it where to find the files used to control individual domains, which are usually referred to as zones when discussing DNS administration.

Here is an sample named.conf, in which the global section instructs named to try to resolve queries through an ISP's DNS servers before falling back on the root servers if the ISP's servers fail to respond. After that, a few sample zone configurations are given - but as you will see, in most cases, the majority of the detail in individual zones is in the zone files themselves.

// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.4 2001/12/05 22:10:12 cjc Exp $
//
// Refer to the named.conf(5) and named(8) man pages for details.  If
// you are ever going to setup a primary server, make sure you've
// understood the hairy details of how DNS is working.  Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amount of useless Internet traffic.

options {
        directory "/etc/namedb";

// Limit to using forwarders ONLY by enabling the following line:
//
//      forward only;

// Set forwarders to attempt to resolve DNS queries at lower-level
// caching DNS servers (typically, your ISP's), reducing load on 
// the root servers and the internet in general.  NOTE: even without
// setting "forward only", using frequently-broken forwarders will, 
// sadly, DRASTICALLY impact your own performance.

      forwarders {
              4.21.223.2;
              4.21.223.2;
      };

        
      // Set query-source address to force a specific source port
      // for outbound queries.
      //
        // query-source address * port 53;

        /*
         * Specify a location for the dumpfile (may be necessary if running in a sandbox)
         */
        // dump-file "s/named_dump.db";
};

// If you are running a local name server, don't forget to put 127.0.0.1 in the first place
// in your /etc/resolv.conf and enable it in /etc/rc.conf.


// Ultimately, DNS queries are an example of hierarchical buck-passing: root queries begin
// with the [[root servers]] for the internet, which don't know the answer, and possibly not
// even who does know the answer - but they know how to get you one step closer.  The buck keeps
// passing downwards until you finally reach the [[authoritative nameserver]] for the record
// you're trying to resolve. This entry points out the [[root servers]] if your server should
// need them.

zone "." {
        type hint;
        file "named.root";
};

// This is a simple "reverse zone", which points IP addresses to [[canonical DNS names]] instead
// of vice-versa.  Ideally, you should have a complete zone file for your LAN IP space as well as
// the subnet your WAN occupies.  In practice, many smaller companies never get this done properly.

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

// This is a reverse IPv6 zone.  We won't have enough IPv4 (dotted quad style) addresses for 
// everybody forever.  Life will not be fun when six-bone is a necessity.  Life will be even LESS
// fun in the last, gruesome days of the necessary switch.  (Look at this monster!)

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
        type master;
        file "localhost.rev";
};

// This is a simple slave zone.  We don't actually write or control this zone file, we just
// ask its real master if we can have a copy of it so that we can help distribute it to others.
// NOTE: attempting to slave a domain that you don't have any business with is VERY frowned upon.

zone "slavedomain.com" {
        type slave;
        file "zones/slavedomain.com";
        masters {
                65.43.99.11;
        };
};

// This is a simple master zone.  We originate and control the zone file which describes this
// zone.  We may or may not choose to allow others to slave it for us.  In this case, we are
// not securing it, so anyone who wants to slave it may do so.

zone "masterdomain.net" {
        type master;
        file "zones/masterdomain.net";
};

// This is a dynamically updated zone.  We originate and control it, but only a small "seed"
// is statically maintained on the server - the rest is updated, deleted, refreshed, etc by
// clients with no fixed IP address as they need to in order to let others find them.  The 
// privilege to update records in this zone is secured with a crypto key.  The key is *not*
// visible to simple queries from the internet.

key dynamic.domain.net. {
        algorithm "HMAC-MD5";
        secret "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f+uIIxxei8qm7AVgNBprxtcU+FQMzBvU/Y+nyM2xbs/C8kF3eJQUA=="";
};

zone "dynamic.domain.net" {
        type master;
        file "zones/dynamic.domain.net";
        allow-update{
                key dynamic.domain.net;
        };
};

Zone files

This is a simple zone file which corresponds to the masterdomain.net entry outlined in the sample named.conf above. In our example configuration, this file is /etc/namedb/zones/masterdomain.net.

$ORIGIN net.
$TTL 5m

masterdomain    IN     SOA    www.masterdomain.net. hostmaster.www.masterdomain.net. (
                                  1               ; serial
                                  4h              ; refresh
                                  15m             ; retry
                                  8h              ; expire
                                  4m)             ; negative caching TTL
                IN      NS      ns1.masterdomain.net.
                IN      NS      ns2.masterdomain.net.
                MX      10      mail.masterdomain.net.
                IN      A       68.96.111.12

$ORIGIN masterdomain.net.
www             IN      CNAME   masterdomain.net.
ns1             IN      A       68.96.111.10
ns2             IN      A       68.96.111.11

This is a very simple (but serviceable) zone file, with one webserver that responds to either masterdomain.net or www.masterdomain.net, and two individual nameservers. (These nameservers will also be configured in the root servers, since masterdomain.net is a top level domain. For more complex examples, see also DNS record types and BIND (dynamic DNS).