See Also: named(8), named.conf(5), DNSHowto, ZoneFile, DNSBestPractices

If you have any problems with your zone files, you probably forgot a "."

You can generate huge sections of your zone file (for dhcp entries for instance) by using $GENERATE, for example
$GENERATE 150-250 $ PTR dhcp-$

MX's and NS records can't point to CNAMEs or directly to raw IP addresses, point them to something with an A or AAAA (or A6) record.

You can have more than one record type for a domain/host, so long as none of them as CNAMEs. ie: you can have two A's, or an A and a TXT, but never an A and a CNAME, or an TXT and a CNAME, or even two CNAMES.

The same applies to DNAME's (you can't have a DNAME and any other record type, including another DNAME or CNAME).

You can define seperate TTL's (in seconds) for records e.g.
shortttl 3600 IN A

This will give a TTL of an hour

Try and have names for services (such as "proxy", "www", "smtp" etc) as this means when you move a service onto a different machine you can change the DNS once and everything will be updated. See DNSBestPractices for examples.

Try and use one name for a NS record for all zones that reside on that machine. for example in "" use "" and in "" use "", this means that when "" changes it's IP, you will only have to update it once for each registrar, not once per registrar per zone. This also means that DNS caches don't fill up with needless entries. Try to make sure that this name server has glue to avoid unnecessary lookups.

An example zone file:

 $TTL 3600
 @        IN       SOA (
                   2005071300        ; serial (in YYYY-mm-dd revision format)
                   10800             ; refresh (10800 seconds = 3 hours)
                   3600              ; retry (3600 seconds = 1 hour)
                   3628800          ; expire ( 6 weeks)
                   86400 )           ; negative cache time-to-live
 @        604800 IN       NS
 @        604800 IN       NS
 @               IN       MX 10
 @               IN       MX 20
 ns1      604800 IN       A
 ns2      604800 IN       A
 smtp            IN       A
 box1            IN       A
 proxy           IN       CNAME box1
 pop3            IN       CNAME box1
 www             IN       CNAME box1
 news            IN       CNAME box1

See ZoneFile for a more verbose description.

Useful config tweaks (possibly Debian-specific).

(found at

1) Run bind as non-root. Create a bind user with home directory of /var/cache/bind, chmod -R bind.bind /var/cache/bind, and add OPTIONS="-u bind -g bind" to /etc/default/bind. This will have the side-affect of preventing named from listening on interfaces that get created after it starts.

2) Add "category statistics { null; };" into the logging section of /etc/bind/named.conf to prevent stats going into syslog.

Root zone Debian woody (bind ver 8) - etc/bind/named.conf:

 zone "." {
        type hint;
        file "/etc/bind/db.root";

Red Hat 8 (bind ver 9) -

 zone  "." {
         type hint;
         file  "";

(this file should live in /var/named/)

ISC has recently released a patch that fixes problems with the Verisign wildcard on the .com and .net root zones. The patch only allows delegations from the root zones and will ignore any A records that are returned directly from the root zone. This seems to be quite a tidy solution to the problem.

You can find more details about the patch at the URL below.

I've written a script to check for obvious mistakes in zone files (forgotten a "." or forgotten to update the serial).

In named.conf in Debian woody there is this comment: </verbatim> options {

directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want // to talk to, you might need to uncomment the query-source // directive below. Previous versions of BIND always asked // questions using port 53, but BIND 8.1 and later use an unprivileged // port by default.

//query-source address * port 53;

... } </verbatim> I found that when using the standard ipmasq scripts ( in /usr/share/doc/ipmasq/examples/stronger ) to create a firewall then, despite what the comment says that uncommenting that line caused dns lookups to stop working, ie the firewall blocked them from going out.

If you run nscd (if you don't know, you probably are...) and running named on the same machine then you should disable nscd's use of DNS, edit /etc/nscd.conf and put
enable-service hosts off

If the link to your DNS server is slow enough (or unreliable enough) that you do want some caching, turning the times down on nscd's caching helps solve a lot of weird issues

positive-time-to-live hosts 60 negative-time-to-live hosts 10

causes it to cache successful responses for 60s and failed responses for 10 seconds. This means that when you look something up it will be cached for a short time and then immediately flushed from the cache rather than nscd's habit of caching bad data.

nscd also believes that hosts are a symmetric relationship. Thus if "" resolves to "localhost" then localhost must resolve to "". Imagine not only the fun you have trying to diagnose these issues, but the potential for evildoers to screw with your security.