datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Common DNS Operational and Configuration Errors
RFC 1912

Document type: RFC - Informational (February 1996)
Obsoletes RFC 1537
Was draft-rfced-info-barr (individual)
Document stream: Legacy
Last updated: 2013-03-02
Other versions: plain text, pdf, html

Legacy State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 1912 (Informational)
Responsible AD: (None)
Send notices to: No addresses provided

Network Working Group                                            D. Barr
Request for Comments: 1912             The Pennsylvania State University
Obsoletes: 1537                                            February 1996
Category: Informational

            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.

Abstract

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

1. Introduction

   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
   addresses.

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

[include full document text]