507 lines
19 KiB
Plaintext
507 lines
19 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|