4.5 Host Name Checking (BIND 4.9.4 and Later Versions)

If your name server is older than BIND 4.9.4 or is BIND 9 through 9.1.0,^[3] skip to the next section.

^[3] Name checking isn't implemented in BIND 9 through 9.1.0. It may be implemented in a future version of BIND 9, though, so you may still need to read this section.

If your name server is BIND 4.9.4 or newer, you have to pay extra attention to how your hosts are named. Starting with Version 4.9.4, BIND checks host names for conformance to RFC 952. If a host name does not conform, BIND considers it a syntax error.

Before you panic, you need to know that this checking applies only to names that are considered host names. Remember, resource records have a name field and a data field; for example:

<name>      <class>  <type>  <data>
terminator  IN       A       192.249.249.3

Host names are in the name fields of A (address) and MX (covered in Chapter 5 ) records. Host names are also in the data fields of SOA and NS records. CNAMEs do not have to conform to the host naming rules because they can point to names that are not host names.

Let's look at the host naming rules. Host names are allowed to contain alphabetic characters and numeric characters in each label. The following are valid host names:

ID4            IN A 192.249.249.10
postmanring2x  IN A 192.249.249.11

A hyphen is allowed if it is in the middle of a label:

fx-gateway     IN A 192.249.249.12

Underscores are not allowed in host names.

Names that are not host names can consist of any printable ASCII character.

If a resource record data field calls for a mail address (as in SOA records), the first label, since it is not a host name, can contain any printable character, but the rest of the labels must follow the host name syntax just described. For example, a mail address has the following syntax:

<ASCII-characters>.<hostname-characters>

For example, if your mail address is key_grip@movie.edu, you can use it in an SOA record even with the underscore. Remember, in a mail address you replace the "@" with a "." like this:

movie.edu. IN SOA terminator.movie.edu. key_grip.movie.edu. (
                          1        ; Serial
                          3h       ; Refresh after 3 hours
                          1h       ; Retry after 1 hour
                          1w       ; Expire after 1 week
                          1h )     ; Negative caching TTL of 1 hour

This extra level of checking can cause dramatic problems at sites that upgrade from a liberal version of BIND to a conservative one, and especially sites that have standardized on host names containing an underscore. If you need to postpone changing names until later (you will still change them, right?), this feature can be toned down to produce warning messages instead of errors or to simply ignore illegal names altogether. The following BIND 4 configuration file statement turns the errors into warning messages:

check-names primary warn

Here is the equivalent BIND 8 or BIND 9 line:

options {
        check-names master warn;
};

The warning messages are logged with syslog, which we'll explain shortly. The following BIND 4 configuration file statement ignores the errors entirely:

check-names primary ignore

Here is the equivalent BIND 8 or BIND 9 line:

options {
        check-names master ignore;
};

If the nonconforming names came from a zone that you back up (and have no control over), then add a similar statement that specifies secondary instead of primary :

check-names secondary ignore

For BIND 8 or 9, use slave instead of secondary :

options {
        check-names slave ignore;
};

And if the names come in responses to queries and not in zone transfers, specify response instead:

check-names response ignore

For BIND 8:

options {
        check-names response ignore;
};

Here are the 4.9.4 defaults:

check-names primary fail
check-names secondary warn
check-names response ignore

Here are BIND 8's defaults:

options {
        check-names master fail;
        check-names slave warn;
        check-names response ignore;
};

In BIND 8, name checking can be specified on a per-zone basis, in which case it overrides name checking behavior specified in the options statement for this particular zone:

zone "movie.edu" in {
        type master;
        file "db.movie.edu";
        check-names fail;
};

The options line contains three fields (check-names master fail ), whereas the zone line check contains only two fields (check-names fail ). This is because the zone line already specifies the context (the zone named in the zone statement).