Interoperability and Version Problems (DNS and BIND, 4th Edition)

14.5. Interoperability and Version Problems

With the move to BIND 9 and the introduction of Microsoft DNS Server, more interoperability problems are cropping up between name servers. There are also a handful of problems unique to one version or another of BIND or the underlying operating system. Many of these are easy to spot and correct, and we would be remiss if we didn't cover them.

14.5.1. Zone Transfer Fails Because of Proprietary WINS Record

When a Microsoft DNS Server is configured to consult a WINS server for names it can't find in a given zone, it inserts a special record into the zone data file. The record looks like this:

@   IN   WINS   &IP address of WINS server

Unfortunately, WINS is not a standard record type in the IN class. Consequently, if there are BIND slaves that transfer this zone, they'll choke on the WINS record and refuse to load the zone:

May 23 15:58:43 terminator named-xfer[386]: "fx.movie.edu IN 65281" - unknown type (65281)

The workaround for this is to configure the Microsoft DNS Server to filter out the proprietary record before transferring the zone. You do this by selecting the zone in the left-hand side of the DNS Manager screen, right-clicking on it, and selecting Properties. Click on the WINS Lookup tab in the resulting Zone Properties window, shown in Figure 14-1.

Figure 14-1. Zone Properties window

Checking Settings only affect local server will filter out the WINS record for that zone. However, if there are any Microsoft DNS Server slaves, they won't see the record either, even though they could use it.

14.5.2. Name Server Reports "No NS Record for SOA MNAME"

You'll see this error only on BIND 8.1 servers:

May 8 03:44:38 terminator named[11680]: no NS RR for SOA MNAME "movie.edu" in
     zone "movie.edu"

The 8.1 server was a real stickler about the first field in the SOA record. Remember that one? In Chapter 4, "Setting Up BIND", we said that it was, by convention, the domain name of the primary master name server for the zone. BIND 8.1 assumes it is and checks for a corresponding NS record pointing the zone's domain name to the server in that field. If there's no such NS record, BIND emits that error message. It will also prevent NOTIFY messages from working correctly. The solution is either to change your MNAME field to the domain name of a name server listed in an NS record or to upgrade to a newer version of BIND 8. Upgrading is the better option since BIND 8.1 is so old. The check was removed at BIND 8.1.1.

14.5.3. Name Server Reports "Too Many Open Files"

On hosts with many IP addresses or a low limit on the maximum number of files a user can open, BIND will report:

Dec 12 11:52:06 terminator named[7770]: socket(SOCK_RAW): Too many open files

and die.

Since BIND tries to bind( ) to and listen on every network interface on the host, it may run out of file descriptors. This is especially common on hosts that use lots of virtual interfaces, often in support of web hosting. The possible solutions are:

Use name-based virtual hosting, which doesn't require additional IP addresses.
Configure your BIND 8 or 9 name server to listen on only one or a few of the host's network interfaces using the listen-on substatement. If terminator.movie.edu is the host we're having this problem with, the following:
```
options {
listen-on { 192.249.249.3; };
};
```

will tell named on terminator.movie.edu to bind( ) only to the IP address 192.249.249.3.
Reconfigure your operating system to allow a process to open more file descriptors concurrently.

14.5.4. Resolver Reports "Looked for PTR, Found CNAME"

This is another problem related to BIND's strictness. On some lookups, the resolver logs:

Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for
     "37.103.74.204.in-addr.arpa IN PTR", got type "CNAME"
Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for
     "37.103.74.204.in-addr.arpa", got "37.32/27.103.74.204.in-addr.arpa"

What happened here is that the resolver asked the name server to reverse map the IP address 204.74.103.37 to a domain name. The server did, but in the process found that 37.103.74.204.in-addr.arpa was actually an alias for 37.32/27.103.74.204.in-addr.arpa. That's almost certainly because the folks who run 103.74.204.in-addr.arpa are using the scheme we described in Chapter 9, "Parenting", to delegate part of their namespace. The BIND 4.9.3-BETA resolver, however, doesn't understand that and flags it as an error, thinking it didn't get the domain name or the type it was after. And, believe it or not, some operating systems ship with the BIND 4.9.3-BETA resolver as their system resolver.

The only solution to this problem is to upgrade to a newer version of the BIND resolver.

14.5.5. Name Server Startup Fails Because UDP Checksums Disabled

On some hosts running SunOS 4.1.x, you'll see this error:

Sep 24 10:40:11 terminator named[7770]: ns_udp checksums NOT turned on: exiting

named checked to make sure UDP checksumming was turned on on this system, and it wasn't, so named exited. named is insistent on UDP checksumming for good reason: it makes copious use of UDP and needs those UDP datagrams to arrive unmolested.

The solution to this problem is to enable UDP checksums on your system. The BIND distribution has documentation on that in shres/sunos/INSTALL and shres/sunos/ISSUES (in the BIND 4 distribution) or src/port/sunos/shres/ISSUES (in the BIND 8 distribution).

14.5.6. SunOS Resolver Is Configured, but Host Doesn't Use DNS

This problem is implementation-specific. Some administrators on SunOS 4 hosts configure their resolvers with resolv.conf and naively assume that ping, telnet, and their brethren should work right away. However, in Chapter 6, "Configuring Hosts" we discussed how SunOS 4 implements the resolver (in ypserv, you may recall). If the host isn't running NIS, configuring the resolver won't do it. The administrator will either have to set up at least an empty hosts map or replace the resolver routines. For details on both of these options, see Section 6.1, "The Resolver" in Chapter 6, "Configuring Hosts".

14.5.7. Other Name Servers Don't Cache Your Negative Answers

You'd need a keen eye to notice this problem, and, if you're running BIND 8, you'd also have to have turned off an important feature to have caused the problem. If you're running BIND 9, though, the feature is turned off by default. If you're running a BIND 8 or 9 name server and other resolvers and servers seem to ignore your server's cached negative responses, auth-nxdomain is probably off.

auth-nxdomain is an options substatement that tells a BIND 8 or 9 name server to flag cached negative responses as authoritative, even though they're not. That is, if your name server has cached the fact that titanic.movie.edu does not exist from the authoritative movie.edu name servers, auth-nxdomain tells your server to pass along that cached response to resolvers and servers that query it as though it were the authoritative name server for movie.edu.

The reason this feature is sometimes necessary is that some name servers check to make sure that negative responses (like an NXDOMAIN return code or no records with a NOERROR return code) are marked authoritative. In the days before negative caching, negative responses had to be authoritative, so this was a sensible sanity check. With the advent of negative caching, however, a negative response could come from the cache. To make sure that older servers don't ignore such answers, though, or consider them errors, BIND 8 and 9 let you falsely flag those responses as authoritative. In fact, that's the default behavior for a BIND 8 name server, so you shouldn't see remote queriers ignoring your BIND 8 server's negative responses unless you've explicitly turned off auth-nxdomain. BIND 9 name servers, on the other hand, have auth-nxdomain offby default, so queriers may ignore their responses even if you haven't touched the config file.

14.5.8. TTL Not Set

As we mentioned in Chapter 4, "Setting Up BIND", RFC 2308 was published just before BIND 8.2 was released. RFC 2308 changed the semantics of the last field in the SOA record to be the negative caching TTL and introduced a new control statement, $TTL, to set the default TTL for a zone data file.

If you upgrade to a BIND 8 name server newer than 8.2 without adding the necessary $TTL control statements to your zone data files, you'll see messages like this one in your name server's syslog output:

Sep 26 19:34:39 terminator named[22116]: Zone "movie.edu" (file db.movie.edu): No 
default TTL ($TTL <value>) set, using SOA minimum instead

BIND 8 generously assumes that you just haven't read RFC 2308 yet and is content to use the last field of the SOA record as both the zone's default TTL and its negative caching TTL. BIND 9, however, isn't so forgiving:

Sep 26 19:35:54 terminator named[22124]: dns_master_load: db.movie.edu:7: no TTL 
specified
Sep 26 19:35:54 terminator named[22124]: dns_zone_load: zone movie.edu/IN: 
database db.movie.edu: dns_db_load failed: no ttl
Sep 26 19:35:54 terminator named[22124]: loading zones: no ttl
Sep 26 19:35:54 terminator named[22124]: exiting (due to fatal error)

So before upgrading to BIND 9, be sure that you add the necessary $TTL control statements.