Zone Data Mistakes

I mentioned RFC 1912 earlier. Much of the RFC deals with mistakes in zone data files. Running nslint or dnswalk (for both, see Chapter 7) helps you find such mistakes. Some of the most common are as follows:

• The HINFO record takes two items of data: the CPU and the OS fields. If one of the fields contains whitespace, it must be quoted as follows:

   tdr     HINFO   "IBM PC"  OpenBSD 

  Always quoting the values is a good idea.

• Matching A and PTR records. The named A record pointed to by a PTR record should point back to the address of the PTR record. Even if a host has several A records pointing to it, only one PTR record is expected. Using a tool such as mkrdns (see Chapter 7) to generate reverse zones is a good idea, but nslint and dnswalk will also discover this.

• The SOA record has two fields before all the numerical fields:

• The first field is the domain name of the primary master server. This must not be a CNAME. The second field is the email address of the hostmaster, the person to contact about DNS matters. This field can't contain a @; instead of the @, use . (period). If the email address of the hostmaster contains periods then they can be escaped like this: \.. So, if the email address of the hostmaster is [e-mail], the SOA record should start this way:

   @       SOA     ns.penguin.bv nicolai\.langfeldt.penguin.bv (         ... 

  Otherwise, the SOA record must contain sensible values for the rest of the fields. See Chapter 2 for a discussion of this. Additionally, the mailbox referred to by the SOA record should be read frequently. Important mail, such as a message telling you your domain is broken and how to fix it, could arrive there at any time.

• Zones should not contain glue A records for any zone that is not directly delegated from the same zone. BIND 8 rejects such inappropriate glue records, logging them each time. A glue A record is the A record belonging with an NS record. For example, penguin.bv contains this NS record:

   @       NS      ns.herring.bv. 

  But it does not contain any A record for ns.herring.bv because the A record can be found other ways, and including it in your zone requires that you update it whenever ns.herring.bv's address is changed. In the old days, we did include such glue records, but in practice they were not kept up-to-date and were found to be a liability. On the other hand, for zones delegated from the penguin.bv zone, a glue record is required:

   emperor         NS      ns.emperor ns.emperor      A       192.168.56.3 

  Otherwise, because emperor is a subdomain of penguin.bv, no way to find the address of ns.emperor.penguin.bv exists.

• MX, SOA, and NS records referring to a CNAME are not legal. These records can refer only to names that have A records.

• Wildcards don't always work as you hoped. For more about them, and CNAME records, please refer to Chapter 3.

• Forgetting the ending . in fully qualified names. If you write

   esr     MX mail.penguin.bv         MX mail.walruss.bv 

  in the penguin.bv zone file, you will see MX records pointing to mail.penguin.bv.penguin.bv and mail.walruss.bv.penguin.bv in DNS.

In general, after editing and reloading a zone, it's a good idea to try to resolve the names you added or made changes to, to verify that BIND thinks your edits mean the same as you think they do. As mentioned before, you should look at the logs when (re)loading zone data BIND might reject the whole zone due to some silly mistake and stop serving the zone.