Upgrading to BIND 9: The Top Nine Gotchas

1. BIND 9 handles errors in zone data files differently.

   BIND 9 will refuse to load a zone that contains just about any syntax error, or one of many logical errors. Earlier versions of BIND were much more forgiving. So if you've been sailing blithely along, ignoring various warnings in your syslog file, upgrading to BIND 9 may be a rude awakening. All of a sudden, your name server may not load one or more of your zone data files.

   Here are a couple of examples of errors that will cause your BIND 9 name server to fail to load a zone:

   • A single domain name owning a CNAME record and any other record (including another CNAME record)

   • Missing fields in resource records

2. BIND 9 handles errors in named.conf differently.

   An older BIND name server would still start, albeit with a partial configuration, if it found an error in named.conf. For example, you might leave out the masters substatement in a slave zone statement:

   zone "test.example" {
   	type slave;
   	file "bak.test.example";
   };
   

   A BIND 8 name server would simply skip that zone statement and go on. A BIND 9 name server, on the other hand, will fail to start:

   Apr  2 16:05:10 ns1 /usr/local/sbin/named[6501]: zone
   'test.example': missing 'masters' entry
   Apr  2 16:05:10 ns1 /usr/local/sbin/named[6501]: loading
   configuration: failure
   Apr  2 16:05:10 ns1 /usr/local/sbin/named[6501]: exiting
   (due to fatal error)
   

   Related Reading DNS and BIND By Paul Albitz, Cricket Liu

   You'd need to fix the problem by adding the masters substatement before named would even start.

3. The $TTL control statement is now required.

   BIND 9 name servers demand that you specify a default time to live value for the zone with a $TTL control statement in each zone data file (unless you specify an explicit TTL on each record, and who does that?). If you don't, you'll see errors like this:

   Apr  2 14:39:33 ns1 /usr/local/sbin/named[6054]:
   dns_master_load: db.test.example:1: no TTL specified
   Apr  2 14:39:33 ns1 /usr/local/sbin/named[6054]:
   dns_zone_load: zone test.example/IN: loading master file
   db.test.example: no ttl
   

   BIND 8.2 and later name servers would use the last field in the zone's SOA record as the default TTL if no $TTL control statement was specified. (Before BIND 8.2, BIND name servers didn't understand the $TTL control statement at all.)

4. The default zone transfer format in BIND 9 is many-answers.

   BIND 8 supported the new, more efficient many-answers zone transfer format, but defaulted to using the older one-answer format for interoperability's sake: BIND 4 slaves couldn't interpret the many-answers format. In BIND 9, however, the default zone transfer format is many-answers. If you have any BIND 4 slaves at all, you'll need to use server statements in named.conf to instruct your BIND 9 name servers to send them one-answer zone transfers:

   server 10.0.0.1 {	// our poor BIND 4 slave
   	transfer-format one-answer;
   };
   

5. BIND 9 uses rndc instead of ndc.

   BIND 8 introduced ndc, the name daemon controller, which initially just automated the task of finding the name server's PID and sending it a signal to induce it to do something interesting, like reload the name server. In BIND 8.2, ndc became a binary (it had been a shell script) that used a Unix domain socket- or TCP-based "control channel" to send control messages to the running name server. Either version of ndc usually worked right after installing the name server: the old version would track down the server's PID from the file named.pid, while the newer version used a local Unix domain socket to communicate with the name server.

   BIND 9 uses rndc, the successor to ndc, to control the name server. rndc uses an authenticated control channel to send messages to the name server. This is significant both because it helps mitigate the risk of someone spoofing a message to the control channel and because it means that rndc doesn't work "out of the box."

   To use rndc at all, you need to create an rndc.conf file and add a key statement and a controls statement to your named.conf file. Here's a small, sample rndc.conf file, which usually lives in /etc:

   options {
           default-server localhost;
           default-key "rndc-key";
   };
   
   key "rndc-key" {
           algorithm hmac-md5;
           secret "jZhJ6D0KwJapRhr4Ln6RYQ==";
   };
   

   This tells rndc to present the key named rndc-key, by default, to the name server running on the local host when it has a command to send. The corresponding key and controls statement in named.conf would look like this:

   controls {
           inet * allow { any; } keys { "rndc-key"; };
   };
   
   key "rndc-key" {
           algorithm hmac-md5;
           secret "jZhJ6D0KwJapRhr4Ln6RYQ==";
   };
   

   This tells named to listen on all local network interfaces ("*") for control messages and to allow them to come from any IP address as long as they're signed with the key rndc-key. The key statement is exactly the same as the statement in rndc.conf.

   Note that it's important that the name of the key, not just the secret that the key points to, matches in rndc.conf and named.conf since rndc uses the name to identify the key that was used to produce the hash value that authenticates the control message.

6. BIND 9 strictly enforces zone boundaries.

   Older BIND name servers would let you get away with configurations like this:

   subdomain     IN     NS      ns1
   subdomain     IN     TXT     "Delegated subdomain"
   

   Technically, that TXT record belongs in the zone data file for subdomain, not in the parent zone. Older versions of BIND, however, would allow it. Not BIND 9, though; it ignores the TXT record as "out-of-zone data."

   This rigidity can also cause problems with delegation information in parent zones. Many administrators take advantage of the automatic "promotion" of NS records in a delegated zone into the parent zone within a single name server. For example, if your BIND 8 name server is configured both as the primary master for bar.example and as a slave for foo.bar.example, it will automatically "promote" the NS records in the foo.bar.example zone into the delegation information for foo.bar.example in the bar.example zone, obviating the need for you to maintain the delegation information manually.

   BIND 9, however, won't mix the subzone's information with the parent zone's. So when a bar.example slave requested a transfer of the zone, it wouldn't include the foo.bar.example NS records.

   This also affects stub zones: a BIND 9 name server won't "promote" NS records from a stub zone into its parent zone. You can, however, configure all of the parent zone's name servers with the stub child zone.

7. BIND 9 is multithreaded.

   Unless you build BIND 9 with

   ./configure --disable-threads
   

   you'll end up with a multithreaded name server. That's cool (as long as your operating system has a good threads implementation) because it'll let your name server take advantage of any extra CPUs your computer may have stashed away. But you may find the consequent output of ps confusing:

   % ps ax | grep named
   6052 ?        S      0:00 /usr/local/sbin/named
   6053 ?        S      0:00 /usr/local/sbin/named
   6054 ?        S      0:00 /usr/local/sbin/named
   6055 ?        S      0:00 /usr/local/sbin/named
   6056 ?        S      0:00 /usr/local/sbin/named
   6318 pts/0    S      0:00 grep named
   

   What are all those extra processes? They're a byproduct of using threads: each thread shows up as a separate process in the process list. It's nothing to be afraid of.

   By the way, if you need to stop or reload the name server, remember to use rndc instead of sending signals to named.

8. BIND 9 doesn't support name checking.

   Some wouldn't view this as a gotcha since it liberalizes the characters that BIND accepts in domain names, but it's worth noting. All versions of BIND from 4.9.4 through BIND 8 implement name checking and forbid illegal characters in domain names that refer to hosts (which, to BIND, means "domain names that own address records"). Legal characters are alphanumerics and dash.

   BIND 9 doesn't implement name checking, though. You can use any characters you want in domain names, including underscores. You should keep in mind, however, that many resolvers now implement name checking, and may not be able to resolve domain names with weird characters.

9. BIND 9 developers don't hang out in the same old places.

   In the past, you could expect to find BIND developers hanging out in the bind-users mailing list, which was bidirectionally gatewayed to the Usenet newsgroup comp.protocols.dns.bind. Send a message there about your woes getting named.conf's syntax right and you'd often get a response back within minutes.

   The BIND 9 developers, however, hang out in the more exclusive bind9-users mailing list. (There's no equivalent newsgroup yet.) If you have questions about BIND 9 in particular, you should ask them there. Better yet--before you ask, check the mailing list's archive or the searchable archive.

Cricket Liu is coauthor of both of O'Reilly & Associates' handbooks on the Domain Name System, DNS and BIND and DNS on Windows NT, and he is the principal author of Managing Internet Information Services. Recently, Cricket finished the fourth edition of DNS and BIND, to cover BIND versions 8.2.3 and 9.1.0.

Cricket worked for five and a half years at Hewlett-Packard's Corporate Network Services, where he ran hp.com, one of the largest corporate domains in the world, and helped design the HP Internet's security architecture. Cricket left HP in 1997 to start his own company, Acme Byte & Wire, with his friend and coauthor Matt Larson. Network Solutions acquired Acme Byte & Wire in June of 2000, and then subsequently, Network Solutions merged with VeriSign. Cricket became director of DNS Product Management in the merged company, helping to determine which new DNS-related products VeriSign would offer.

O'Reilly & Associates will soon release (April 2001) DNS and BIND, 4th Edition.

• Sample Chapter 11, Security, is available free online.

• You can also look at the Full Description of the book.

• For more information, or to order the book, click here.

Sponsored by: