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