Domain system changes and observations
RFC 973
|
Document |
Type |
|
RFC - Unknown
(January 1986; No errata)
|
|
Authors |
|
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 973 (Unknown)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group Paul Mockapetris
Request for Comments: 973 ISI
January 1986
Domain System Changes and Observations
STATUS OF THIS MEMO
This RFC documents updates to Domain Name System specifications
RFC-882 [1] and RFC-883 [2], suggests some operational guidelines,
and discusses some experiences and problem areas in the present
system. Distribution of this memo is unlimited.
This document includes all changes to the Domain System through
January, 1986. Change notices and additional discussion are
available online in file [USC-ISIB.ARPA]<DOMAIN>DOMAIN.CHANGES.
OVERVIEW
This memo is divided into four major sections:
"UPDATES" which discusses changes to the domain specification
which are in widespread use and should be regarded as being part
of the specification.
"OPERATION GUIDELINES" which suggests rules-of-thumb for using the
domain system and configuring your database which are appropriate
in most cases, but which may have rare exceptions.
"EXPERIENCES" which discusses some unusual situations and common
bugs which are encountered in the present system, and should be
helpful in problem determination and tuning.
"PROBLEM AREAS" which discusses some shortcomings in the present
system which may be addressed in future versions.
UPDATES
This section discusses changes to the specification which are final,
and should be incorporated in all domain system software.
TTL timeouts too small
The 16 bit TTL field in RRs could not represent a large enough
time interval. The 16 bit field, using seconds for units, has a
maximum period of approximately 18 hours.
All time values, including all TTLs and the MINIMUM field of the
SOA RR, are expanded to 32 bits.
Mockapetris [Page 1]
RFC 973 January 1986
Domain System Changes and Observations
CLASS changes
Class 2, originally reserved for CSNET, is obsolete. Class 3 has
been assigned for use by CHAOS.
CNAME usage
The specification allows CNAME RRs to exist with other RRs at the
same node. This creates difficulties since the other RRs stored
with the CNAME at the alias might not agree with the RRs stored at
the primary name.
If a node has a CNAME RR, it should have no other RRs.
* semantics
The use of * to represent a single label wildcard, along with the
possibility of multiple * labels, led to difficult server
implementations and complicated search algorithms. There were
also questions regarding whether a * based specification could
refer to names that were not contained in the zone which had the *
specification.
While we might want the "inheritability" for some cases, it leads
to implementation difficulties. The first of these is that
whenever we can't find a RR in a particular zone, we have to
search all parent zones to look for a suitable * result.
(Alternatively we could develop some automatic method for insuring
consistency or insist on careful duplication of inherited data.)
We also must deal with conflicts, i.e. what if a subdomain doesn't
want to inherit defaults.
Given these difficulties, the solution is to insist that
delegation of authority cancels the * defaults. This is quite
simple to implement; all you need to do is to check for delegation
before looking for * RRs.
A second difficulty is the restriction that * match a single
label. Thus if a name server is looking for RRs for the name
A.B.C.D.E.F, it must check for *.B.C.D.E.F, *.*.C.D.E.F,
*.*.*.D.E.F, etc. This check must also be careful of zone
boundaries and multiplies the effort to handle a query.
The solution adopted is to allow a single * label in the leftmost
part of a name stored in a zone, and to allow this label to match
Mockapetris [Page 2]
RFC 973 January 1986
Domain System Changes and Observations
any number of unknown labels or a single known label in the query
name. However, the * match is only taken for parts of the tree
which are neither delegated or explicitly represented.
The algorithm for performing the search in a tree structured
database has the following steps:
1) Descend in the tree matching labels from right to left. If a
delegation is found return that; if the specified node is found
go to step 2, if the tree ends go to step 3.
2) Look for RRs that answer the query. If any are found, return
Show full document text