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]
|
|||
|
|