See Also: named(8), named.conf(5), DNSHowto, ZoneFile, DNSBestPractices
If you have any problems with your zone files, you probably forgot a "."
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).
This will give shortttl.domain.co.nz 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 "foo.example.com" use "ns1.example.com" and in "example2.com" use "ns1.example.com", this means that when "ns1.example.com" 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 example.com. soa.example.com. (
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 ns1.example.com.
@ 604800 IN NS ns2.example.com.
@ IN MX 10 smtp.example.com.
@ IN MX 20 smtp.example.org.
ns1 604800 IN A 192.0.2.1
ns2 604800 IN A 10.0.0.1
smtp IN A 192.0.2.1
box1 IN A 192.0.2.2
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 
http://www.cryptio.net/ferlatte/config/)
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 "named.ca";
};
(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 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 "4.3.2.1.in-addr.arpa." resolves to "localhost" then localhost must resolve to "1.2.3.4". Imagine not only the fun you have trying to diagnose these issues, but the potential for evildoers to screw with your security.
7 pages link to NamedNotes:
