If your name server is older than BIND 4.9.4, skip to the next 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 the zone to have a syntax error.
Before you panic, you need to know that this checking only applies 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 field of A (address) and MX (covered in Chapter 5, DNS and Electronic Mail) records. Host names are in the data fields of SOA and NS records. At least in version 4.9.4, CNAMEs do not have to conform to the host naming rules because they can point to names that are not host names.
Here are the host naming rules: host names are allowed to have 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
NOTE: Underscores are not allowed in host names.
Names that are not host names can consist of any printable ASCII character.
If the resource record data field calls for a mail address (SOA records), the first label can contain any printable character, since it is not a host name, but the rest of the labels must follow the host name syntax described above. For example, a mail address has the following syntax:
<ASCII-characters>.<hostname-characters>
For example, if your mail address is [email protected], you can still use it in an SOA record, even with the underscore. Remember, in a mail address you replace the "@" with a ".":
movie.edu. IN SOA terminator.movie.edu. key_grip.movie.edu. ( 1 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day
This extra level of checking might cause dramatic problems to sites that upgrade from a liberal version of BIND to a conservative one, especially sites that standardized on 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 warning messages or simply ignored altogether. The following version 4 configuration file statement turns the errors into warning messages:
check-names primary warn
Here is the equivalent version 8 line:
options { check-names master warn; };
The warning messages are logged with syslog, which we will explain shortly. The following version 4 configuration file statement ignores the errors:
check-names primary ignore
Here is the equivalent version 8 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 version 8, use slave instead of secondary:
options { check-names slave ignore; };
And if the names came in responses to queries, and not in zone transfers, specify response instead:
check-names response ignore
For version 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 the version 8 defaults:
options { check-names master fail; check-names slave warn; check-names response ignore; };
For version 8, the name checking can be specified on a per-zone basis, in which case it overrides the options statement:
zone "movie.edu" in { type master; file "db.movie"; check-names fail; };
NOTE: The
options
line contains 3 fields (check-names master fail
), whereas the zone line check contains only 2 fields (check-names fail
). This is because thezone
line already specifies the type (type master
).