14.5. Interoperability and Version ProblemsWith 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 RecordWhen 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:
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:@ IN WINS &IP address of WINS server
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.May 23 15:58:43 terminator named-xfer: "fx.movie.edu IN 65281" - unknown type (65281)
Figure 14-1. Zone Properties windowChecking 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:
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.May 8 03:44:38 terminator named: no NS RR for SOA MNAME "movie.edu" in zone "movie.edu"
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:
and die.Dec 12 11:52:06 terminator named: socket(SOCK_RAW): Too many open files
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:
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:
What happened here is that the resolver asked the name server to reverse map the IP address 22.214.171.124 to a domain name. The server did, but in the process found that 126.96.36.199.in-addr.arpa was actually an alias for 37.32/188.8.131.52.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.Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for "184.108.40.206.in-addr.arpa IN PTR", got type "CNAME" Sep 24 10:40:11 terminator syslog: gethostby*.getanswer: asked for "220.127.116.11.in-addr.arpa", got "37.32/18.104.22.168.in-addr.arpa"
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 DisabledOn some hosts running SunOS 4.1.x, you'll see this error:
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.Sep 24 10:40:11 terminator named: ns_udp checksums NOT turned on: exiting
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 DNSThis 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 AnswersYou'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 SetAs 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:
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:34:39 terminator named: Zone "movie.edu" (file db.movie.edu): No default TTL ($TTL <value>) set, using SOA minimum instead
So before upgrading to BIND 9, be sure that you add the necessary $TTL control statements.Sep 26 19:35:54 terminator named: dns_master_load: db.movie.edu:7: no TTL specified Sep 26 19:35:54 terminator named: dns_zone_load: zone movie.edu/IN: database db.movie.edu: dns_db_load failed: no ttl Sep 26 19:35:54 terminator named: loading zones: no ttl Sep 26 19:35:54 terminator named: exiting (due to fatal error)
Copyright © 2002 O'Reilly & Associates. All rights reserved.