diff options
Diffstat (limited to 'doc/rfc/rfc1537.txt')
| -rw-r--r-- | doc/rfc/rfc1537.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc1537.txt b/doc/rfc/rfc1537.txt new file mode 100644 index 0000000..81b9768 --- /dev/null +++ b/doc/rfc/rfc1537.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group P. Beertema +Request for Comments: 1537 CWI +Category: Informational October 1993 + + + Common DNS Data File Configuration Errors + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Abstract + + This memo describes errors often found in DNS data files. It points + out common mistakes system administrators tend to make and why they + often go unnoticed for long periods of time. + +Introduction + + Due to the lack of extensive documentation and automated tools, DNS + zone files have mostly been configured by system administrators, by + hand. Some of the rules for writing the data files are rather subtle + and a few common mistakes are seen in domains worldwide. + + This document is an attempt to list "surprises" that administrators + might find hidden in their zone files. It describes the symptoms of + the malady and prescribes medicine to cure that. It also gives some + general recommendations and advice on specific nameserver and zone + file issues and on the (proper) use of the Domain Name System. + +1. SOA records + + A problem I've found in quite some nameservers is that the various + timers have been set (far) too low. Especially for top level domain + nameservers this causes unnecessary traffic over international and + intercontinental links. + + Unfortunately the examples given in the BIND manual, in RFC's and in + some expert documents give those very short timer values, and that's + most likely what people have modeled their SOA records after. + + First of all a short explanation of the timers used in the SOA + record: + + + + + + +Beertema [Page 1] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + - Refresh: The SOA record of the primary server is checked + every "refresh" time by the secondary servers; + if it has changed, a zone transfer is done. + + - Retry: If a secondary server cannot reach the primary + server, it tries it again every "retry" time. + + - Expire: If for "expire" time the primary server cannot + be reached, all information about the zone is + invalidated on the secondary servers (i.e., they + are no longer authoritative for that zone). + + - Minimum TTL: The default TTL value for all records in the + zone file; a different TTL value may be given + explicitly in a record when necessary. + (This timer is named "Minimum", and that's + what it's function should be according to + STD 13, RFC 1035, but most (all?) + implementations take it as the default value + exported with records without an explicit TTL + value). + + For top level domain servers I would recommend the following values: + + 86400 ; Refresh 24 hours + 7200 ; Retry 2 hours + 2592000 ; Expire 30 days + 345600 ; Minimum TTL 4 days + + For other servers I would suggest: + + 28800 ; Refresh 8 hours + 7200 ; Retry 2 hours + 604800 ; Expire 7 days + 86400 ; Minimum TTL 1 day + + but here the frequency of changes, the required speed of propagation, + the reachability of the primary server etc. play a role in optimizing + the timer values. + +2. Glue records + + Quite often, people put unnecessary glue (A) records in their zone + files. Even worse is that I've even seen *wrong* glue records for an + external host in a primary zone file! Glue records need only be in a + zone file if the server host is within the zone and there is no A + record for that host elsewhere in the zone file. + + + + +Beertema [Page 2] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + Old BIND versions ("native" 4.8.3 and older versions) showed the + problem that wrong glue records could enter secondary servers in a + zone transfer. + +3. "Secondary server surprise" + + I've seen it happen on various occasions that hosts got bombarded by + nameserver requests without knowing why. On investigation it turned + out then that such a host was supposed to (i.e., the information was + in the root servers) run secondary for some domain (or reverse (in- + addr.arpa)) domain, without that host's nameserver manager having + been asked or even been told so! + + Newer BIND versions (4.9 and later) solved this problem. At the same + time though the fix has the disadvantage that it's far less easy to + spot this problem. + + Practice has shown that most domain registrars accept registrations + of nameservers without checking if primary (!) and secondary servers + have been set up, informed, or even asked. It should also be noted + that a combination of long-lasting unreachability of primary + nameservers, (therefore) expiration of zone information, plus static + IP routing, can lead to massive network traffic that can fill up + lines completely. + +4. "MX records surprise" + + In a sense similar to point 3. Sometimes nameserver managers enter MX + records in their zone files that point to external hosts, without + first asking or even informing the systems managers of those external + hosts. This has to be fought out between the nameserver manager and + the systems managers involved. Only as a last resort, if really + nothing helps to get the offending records removed, can the systems + manager turn to the naming authority of the domain above the + offending domain to get the problem sorted out. + +5. "Name extension surprise" + + Sometimes one encounters weird names, which appear to be an external + name extended with a local domain. This is caused by forgetting to + terminate a name with a dot: names in zone files that don't end with + a dot are always expanded with the name of the current zone (the + domain that the zone file stands for or the last $ORIGIN). + + Example: zone file for foo.xx: + + pqr MX 100 relay.yy. + xyz MX 100 relay.yy (no trailing dot!) + + + +Beertema [Page 3] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + When fully written out this stands for: + + pqr.foo.xx. MX 100 relay.yy. + xyz.foo.xx. MX 100 relay.yy.foo.xx. (name extension!) + +6. Missing secondary servers + + It is required that there be a least 2 nameservers for a domain. For + obvious reasons the nameservers for top level domains need to be very + well reachable from all over the Internet. This implies that there + must be more than just 2 of them; besides, most of the (secondary) + servers should be placed at "strategic" locations, e.g., close to a + point where international and/or intercontinental lines come + together. To keep things manageable, there shouldn't be too many + servers for a domain either. + + Important aspects in selecting the location of primary and secondary + servers are reliability (network, host) and expedient contacts: in + case of problems, changes/fixes must be carried out quickly. It + should be considered logical that primary servers for European top + level domains should run on a host in Europe, preferably (if + possible) in the country itself. For each top level domain there + should be 2 secondary servers in Europe and 2 in the USA, but there + may of course be more on either side. An excessive number of + nameservers is not a good idea though; a recommended maximum is 7 + nameservers. In Europe, EUnet has offered to run secondary server + for each European top level domain. + +7. Wildcard MX records + + Wildcard MX records should be avoided where possible. They often + cause confusion and errors: especially beginning nameserver managers + tend to overlook the fact that a host/domain listed with ANY type of + record in a zone file is NOT covered by an overall wildcard MX record + in that zone; this goes not only for simple domain/host names, but + also for names that cover one or more domains. Take the following + example in zone foo.bar: + + * MX 100 mailhost + pqr MX 100 mailhost + abc.def MX 100 mailhost + + This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid + domains, but the wildcard MX record covers NONE of them, nor anything + below them. To cover everything by MX records, the required entries + are: + + + + + +Beertema [Page 4] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + * MX 100 mailhost + pqr MX 100 mailhost + *.pqr MX 100 mailhost + abc.def MX 100 mailhost + *.def MX 100 mailhost + *.abc.def MX 100 mailhost + + An overall wildcard MX record is almost never useful. + + In particular the zone file of a top level domain should NEVER + contain only an overall wildcard MX record (*.XX). The effect of such + a wildcard MX record can be that mail is unnecessarily sent across + possibly expensive links, only to fail at the destination or gateway + that the record points to. Top level domain zone files should + explicitly list at least all the officially registered primary + subdomains. + + Whereas overall wildcard MX records should be avoided, wildcard MX + records are acceptable as an explicit part of subdomain entries, + provided they are allowed under a given subdomain (to be determined + by the naming authority for that domain). + + Example: + + foo.xx. MX 100 gateway.xx. + MX 200 fallback.yy. + *.foo.xx. MX 100 gateway.xx. + MX 200 fallback.yy. +8. Hostnames + + People appear to sometimes look only at STD 11, RFC 822 to determine + whether a particular hostname is correct or not. Hostnames should + strictly conform to the syntax given in STD 13, RFC 1034 (page 11), + with *addresses* in addition conforming to RFC 822. As an example + take "c&w.blues" which is perfectly legal according to RFC 822, but + which can have quite surprising effects on particular systems, e.g., + "telnet c&w.blues" on a Unix system. + +9. HINFO records + + There appears to be a common misunderstanding that one of the data + fields (usually the second field) in HINFO records is optional. A + recent scan of all reachable nameservers in only one country revealed + some 300 incomplete HINFO records. Specifying two data fields in a + HINFO record is mandatory (RFC 1033), but note that this does *not* + mean that HINFO records themselves are mandatory. + + + + + +Beertema [Page 5] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + +10. Safety measures and specialties + + Nameservers and resolvers aren't flawless. Bogus queries should be + kept from being forwarded to the root servers, since they'll only + lead to unnecessary intercontinental traffic. Known bogus queries + that can easily be dealt with locally are queries for 0 and broadcast + addresses. To catch such queries, every nameserver should run + primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone + files need only contain a SOA and an NS record. + + Also each nameserver should run primary for 0.0.127.in-addr.arpa; + that zone file should contain a SOA and NS record and an entry: + + 1 PTR localhost. + + There has been extensive discussion about whether or not to append + the local domain to it. The conclusion was that "localhost." would be + the best solution; reasons given were: + + - "localhost" itself is used and expected to work on some systems. + + - translating 127.0.0.1 into "localhost.my_domain" can cause some + software to connect to itself using the loopback interface when + it didn't want to. + + Note that all domains that contain hosts should have a "localhost" A + record in them. + + People maintaining zone files with the Serial number given in dotted + decimal notation (e.g., when SCCS is used to maintain the files) + should beware of a bug in all BIND versions: if the serial number is + in Release.Version (dotted decimal) notation, then it is virtually + impossible to change to a higher release: because of the wrong way + that notation is turned into an integer, it results in a serial + number that is LOWER than that of the former release. + + For this reason and because the Serial is an (unsigned) integer + according to STD 13, RFC 1035, it is recommended not to use the + dotted decimal notation. A recommended notation is to use the date + (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is + or can be more than one change per day in a zone file. + + Very old versions of DNS resolver code have a bug that causes queries + for A records with domain names like "192.16.184.3" to go out. This + happens when users type in IP addresses and the resolver code does + not catch this case before sending out a DNS query. This problem has + been fixed in all resolver implementations known to us but if it + still pops up it is very serious because all those queries will go to + + + +Beertema [Page 6] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + the root servers looking for top level domains like "3" etc. It is + strongly recommended to install the latest (publicly) available BIND + version plus all available patches to get rid of these and other + problems. + + Running secondary nameserver off another secondary nameserver is + possible, but not recommended unless really necessary: there are + known cases where it has led to problems like bogus TTL values. This + can be caused by older or flawed implementations, but secondary + nameservers in principle should always transfer their zones from the + official primary nameserver. + +11. Some general points + + The Domain Name System and nameserver are purely technical tools, not + meant in any way to exert control or impose politics. The function of + a naming authority is that of a clearing house. Anyone registering a + subdomain under a particular (top level) domain becomes naming + authority and therewith the sole responsible for that subdomain. + Requests to enter MX or NS records concerning such a subdomain + therefore always MUST be honored by the registrar of the next higher + domain. + + Examples of practices that are not allowed are: + + - imposing specific mail routing (MX records) when registering + a subdomain. + + - making registration of a subdomain dependent on to the use of + certain networks or services. + + - using TXT records as a means of (free) commercial advertising. + + In the latter case a network service provider could decide to cut off + a particular site until the offending TXT records have been removed + from the site's zone file. + + Of course there are obvious cases where a naming authority can refuse + to register a particular subdomain and can require a proposed name to + be changed in order to get it registered (think of DEC trying to + register a domain IBM.XX). + + There are also cases were one has to probe the authority of the + person: sending in the application - not every systems manager should + be able to register a domain name for a whole university. The naming + authority can impose certain extra rules as long as they don't + violate or conflict with the rights and interest of the registrars of + subdomains; a top level domain registrar may e.g., require that there + + + +Beertema [Page 7] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + be primary subdomain "ac" and "co" only and that subdomains be + registered under those primary subdomains. + + The naming authority can also interfere in exceptional cases like the + one mentioned in point 4, e.g., by temporarily removing a domain's + entry from the nameserver zone files; this of course should be done + only with extreme care and only as a last resort. + + When adding NS records for subdomains, top level domain nameserver + managers should realize that the people setting up the nameserver for + a subdomain often are rather inexperienced and can make mistakes that + can easily lead to the subdomain becoming completely unreachable or + that can cause unnecessary DNS traffic (see point 1). It is therefore + highly recommended that, prior to entering such an NS record, the + (top level) nameserver manager does a couple of sanity checks on the + new nameserver (SOA record and timers OK?, MX records present where + needed? No obvious errors made? Listed secondary servers + operational?). Things that cannot be caught though by such checks + are: + + - resolvers set up to use external hosts as nameservers + + - nameservers set up to use external hosts as forwarders + without permission from those hosts. + + Care should also be taken when registering 2-letter subdomains. + Although this is allowed, an implication is that abbreviated + addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in + and under that subdomain. When requested to register such a domain, + one should always notify the people of this consequence. As an + example take the name "cs", which is commonly used for Computer + Science departments: it is also the name of the top level domain for + Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is + ambiguous in that in can denote both a user on the host + host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia. + (This example does not take into account the recent political changes + in the mentioned country). + +References + + [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, + RFC 1034, USC/Information Sciences Institute, November 1987. + + [2] Mockapetris, P., "Domain Names Implementation and Specification", + STD 13, RFC 1035, USC/Information Sciences Institute, November + 1987. + + + + + +Beertema [Page 8] + +RFC 1537 Common DNS Data File Configuration Errors October 1993 + + + [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC + 974, CSNET CIC BBN, January 1986. + + [4] Gavron, E., "A Security Problem and Proposed Correction With + Widely Deployed DNS Software", RFC 1535, ACES Research Inc., + October 1993. + + [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, + "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, + USC/Information Sciences Institute, USC, October 1993. + +Security Considerations + + Security issues are not discussed in this memo. + +Author's Address + + Piet Beertema + CWI + Kruislaan 413 + NL-1098 SJ Amsterdam + The Netherlands + + Phone: +31 20 592 4112 + FAX: +31 20 592 4199 + EMail: Piet.Beertema@cwi.nl + + +Editor's Address + + Anant Kumar + USC Information Sciences Institute + 4676 Admiralty Way + Marina Del Rey CA 90292-6695 + + Phone:(310) 822-1511 + FAX: (310) 823-6741 + EMail: anant@isi.edu + + + + + + + + + + + + + +Beertema [Page 9] +
\ No newline at end of file |