Network Working Group D. Barr
Request for Comments: 1912 The Pennsylvania State University
Obsoletes: 1537 February 1996
Common DNS Operational and Configuration Errors
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This memo describes errors often found in both the operation of
Domain Name System (DNS) servers, and in the data that these DNS
servers contain. This memo tries to summarize current Internet
requirements as well as common practice in the operation and
configuration of the DNS. This memo also tries to summarize or
expand upon issues raised in [RFC 1537].
Running a nameserver is not a trivial task. There are many things
that can go wrong, and many decisions have to be made about what data
to put in the DNS and how to set up servers. This memo attempts to
address many of the common mistakes and pitfalls that are made in DNS
data as well as in the operation of nameservers. Discussions are
also made regarding some other relevant issues such as server or
resolver bugs, and a few political issues with respect to the
operation of DNS on the Internet.
2. DNS Data
This section discusses problems people typically have with the DNS
data in their nameserver, as found in the zone data files that the
nameserver loads into memory.
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host should have a name. The consequences
of this are becoming more and more obvious. Many services available
on the Internet will not talk to you if you aren't correctly
registered in the DNS.
Barr Informational [Page 1]RFC 1912 Common DNS Errors February 1996
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain. If a
host is multi-homed, (more than one IP address) make sure that all IP
addresses have a corresponding PTR record (not just the first one).
Failure to have matching PTR and A records can cause loss of Internet
services similar to not being registered in the DNS at all. Also,
PTR records must point back to a valid A record, not a alias defined
by a CNAME. It is highly recommended that you use some software
which automates this checking, or generate your DNS data from a
database which automatically creates consistent data.
DNS domain names consist of "labels" separated by single dots. The
DNS is very liberal in its rules for the allowable characters in a
domain name. However, if a domain name is used to name a host, it
should follow rules restricting host names. Further if a name is
used for mail, it must follow the naming rules for names in mail
Allowable characters in a label for a host name are only ASCII
letters, digits, and the `-' character. Labels may not be all
numbers, but may have a leading digit (e.g., 3com.com). Labels must
end and begin only with a letter or digit. See [RFC 1035] and [RFC
1123]. (Labels were initially restricted in [RFC 1035] to start with
a letter, and some older hosts still reportedly have problems with
the relaxation in [RFC 1123].) Note there are some Internet
hostnames which violate this rule (411.org, 1776.com). The presence
of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
is informational only and was not defining a standard. There is at
least one popular TCP/IP implementation which currently refuses to
talk to hosts named with underscores in them. It must be noted that
the language in  is such that these rules are voluntary -- they
are there for those who wish to minimize problems. Note that the
rules for Internet host names also apply to hosts and addresses used
in SMTP (See RFC 821).
If a domain name is to be used for mail (not involving SMTP), it must
follow the rules for mail in [RFC 822], which is actually more
liberal than the above rules. Labels for mail can be any ASCII
character except "specials", control characters, and whitespace
characters. "Specials" are specific symbols used in the parsing of
addresses. They are the characters "()<>@,;:\".". (The "!"
character wasn't in [RFC 822], however it also shouldn't be used due
to the conflict with UUCP mail as defined in RFC 976) However, since
today almost all names which are used for mail on the Internet are