Domain system changes and observations (RFC0973)
Original Publication Date: 1986-Jan-01
Included in the Prior Art Database: 2001-Jul-12
Internet Society Requests For Comment (RFCs)
STATUS OF THIS MEMO
Network Working Group Paul Mockapetris Request for Comments: 973 ISI
Domain System Changes and Observations
STATUS OF THIS MEMO
This RFC documents updates to Domain Name System specifications RFC-882  and RFC-883 , 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]
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.
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 2, originally reserved for CSNET, is obsolete. Class 3 has been assigned for use by CHAOS.
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.
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 authorit...