I l@ve RuBoard |
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.
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
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; };
|
I l@ve RuBoard |