Penguin
Note: You are viewing an old revision of this page. View the current version.

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


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


named(8) lets you generate lines in your zonefile by
$GENERATE 150-250 $.0.0.10.in-addr.arpa. PTR dhcp-$.example.com.

Remember, 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 127.0.0.1

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.


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.


Sample zone file

@ IN SOA foo.com. soa.foo.com. (

2002060700 ; serial 10800 ; refresh (10800 seconds = 3 hours) 3600 ; retry (3600 seconds = 1 hour) 3600000 ; expire 86400 ) ; negative cache time-to-live

@ IN NS ns1.foo.com. @ IN NS ns2.foo.com. @ IN MX 10 smtp.foo.com. @ IN MX 20 smtp.baz.com. ns1 IN A 1.2.3.4 ns2 IN A 1.2.4.5 smtp IN A 1.2.3.4 box1 IN A 1.2.3.6 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.

http://www.isc.org/products/BIND/delegation-only.html


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:

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;

... }

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 "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.