As per Relevance of the word observations, we have this rfc below:
Network Working Group Paul
Request for Comments: 973
January 1986
Domain System Changes and
STATUS OF THIS
This RFC documents updates to Domain Name System
RFC-882 [1] and RFC-883 [2], suggests some operational guidelines
and discusses some experiences and problem areas in the
system. Distribution of this memo is unlimited
This document includes all changes to the Domain System
January, 1986. Change notices and additional discussion
available online in file [USC-ISIB.ARPA]DOMAIN.CHANGES
This memo is divided into four major sections
"UPDATES" which discusses changes to the domain
which are in widespread use and should be regarded as being
of the specification
"OPERATION GUIDELINES" which suggests rules-of-thumb for using
domain system and configuring your database which are
in most cases, but which may have rare exceptions
"EXPERIENCES" which discusses some unusual situations and
bugs which are encountered in the present system, and should
helpful in problem determination and tuning
"PROBLEM AREAS" which discusses some shortcomings in the
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
The 16 bit TTL field in RRs could not represent a large
time interval. The 16 bit field, using seconds for units, has
maximum period of approximately 18 hours
All time values, including all TTLs and the MINIMUM field of
SOA RR, are expanded to 32 bits
Mockapetris [Page 1]
RFC 973 January 1986
Domain System Changes and
CLASS
Class 2, originally reserved for CSNET, is obsolete. Class 3
been assigned for use by CHAOS
CNAME
The specification allows CNAME RRs to exist with other RRs at
same node. This creates difficulties since the other RRs
with the CNAME at the alias might not agree with the RRs stored
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
possibility of multiple * labels, led to difficult
implementations and complicated search algorithms. There
also questions regarding whether a * based specification
refer to names that were not contained in the zone which had the *
specification
While we might want the "inheritability" for some cases, it
to implementation difficulties. The first of these is
whenever we can't find a RR in a particular zone, we have
search all parent zones to look for a suitable * result
(Alternatively we could develop some automatic method for
consistency or insist on careful duplication of inherited data.)
We also must deal with conflicts, i.e. what if a subdomain doesn'
want to inherit defaults
Given these difficulties, the solution is to insist
delegation of authority cancels the * defaults. This is
simple to implement; all you need to do is to check for
before looking for * RRs
A second difficulty is the restriction that * match a
label. Thus if a name server is looking for RRs for the
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
boundaries and multiplies the effort to handle a query
The solution adopted is to allow a single * label in the
part of a name stored in a zone, and to allow this label to
Mockapetris [Page 2]
RFC 973 January 1986
Domain System Changes and
any number of unknown labels or a single known label in the
name. However, the * match is only taken for parts of the
which are neither delegated or explicitly represented
The algorithm for performing the search in a tree
database has the following steps
1) Descend in the tree matching labels from right to left. If
delegation is found return that; if the specified node is
go to step 2, if the tree ends go to step 3.
2) Look for RRs that answer the query. If any are found,
them as the answer. If none are found, look for answers in a *
node which has the same name as the query name except for
rightmost label. (e.g. if you can't find an answer at F.ISI.ARPA
look for a RR at *.ISI.ARPA
3) The search for a desired name has failed; look for a node
name is * plus however much matched. Look for answers there
(e.g. If you are looking for X.Y.ISI.ARPA and the tree ends
ISI.ARPA, look at *.ISI.ARPA. The same thing holds
Y.ISI.ARPA, or any name of the form .Z.ISI.ARPA, where
is a label that doesn't exist under ISI.ARPA
Note that this interpretation means that * matches names that
not in the tree, no matter how much of the tree is missing,
also matches one level's worth of known tree
AA
When a name server is responding to a query for a particular
and finds a CNAME, it may optionally restart the search at
canonical name. If the server uses the restart feature,
answer section of the returned query contains one (or more
CNAMEs, possibly followed by answers for the primary name.
canonical name will usually be in the same zone as the alias,
this need not be the case. If the server is authoritative for
of the names but not both, it is not clear whether the AA
should be set
The solution adopted is to make the AA refer to the original
name
Mockapetris [Page 3]
RFC 973 January 1986
Domain System Changes and
Master file
The present specification uses a somewhat awkward method
representing domain names in master files
The change adopted is that all domain names in this file will
represented as either absolute or relative. An absolute
name ends with a ".". A free standing "." is assumed to refer
the root. A relative domain name doesn't end with a dot, and
assumed to be relative to the current origin
SERIAL number
If the master file changes rapidly, an infrequently updated
may miss the wrapping of the sequence number in the SERIAL
of the SOA, or misinterpret the number of updates that have
place
The SERIAL field is increased to 32 bits
MD and MF replaced by
The original specification uses MD and MF RRs for mail
binding. The problem is that a mailer making a MAILA query,
asks for both types, can't use the cache since the cache
have the results for a MD or MF query. That is, the presence
one of these types of information in the cache doesn't
anything about the other type. The result was that either
would have to always consult authoritative servers or try to
partial information; neither of these is really acceptable
The change is to replace MD and MF with a new type of RR called
which conveys similar information in a single RR type. MX
been assigned a type code of 15 decimal. The format of the MX
is a 16 bit preference value followed by a domain name. A
may have multiple MX RRs, and multiple MX RRs with the
preference value are allowed at a given node
Mockapetris [Page 4]
RFC 973 January 1986
Domain System Changes and
The preference values denote the relative preference that the
destination places on the mail agents, with lower values
"better". A mailer is expected to at least try the mail agent(s
with the lowest preference value. The significance of
preference values, the units of preference, and the linearity
preference values are not defined but left open; preference
should only be used to establish relative rankings
For example, the current RRs
MAIL-ORG MD HOST1
MD HOST2
MF HOST3
might be replaced by
MAIL-ORG MX 10 HOST1
MX 10 HOST2
MX 20 HOST3
The values 10 and 20 have no significance other than 10<20.
detailed discussion of the use of MX is the subject of [3].
Zone
The original specification states that zone transfers take
in breadth first order. The intent was to make the
easier for the accepting name server to handle. This now doesn'
work out to be very helpful, and is a severe pain for
using various hashing algorithms. The new rule is that you
transmit the records in any order you choose, so long as the
node of the zone is transmitted first and last, and no
duplication occurs
IN-ADDR domain
The name of the IN-ADDR domain is now IN-ADDR.ARPA. This
was made because many felt that the use of a top-level name
inappropriate to network-specific information
Mockapetris [Page 5]
RFC 973 January 1986
Domain System Changes and
OPERATIONAL
This section suggests rules-of-thumb for using the domain system
configuring your database which are appropriate in most cases,
which may have rare exceptions
Zone
When a domain wishes to become independent from its parent,
RRs which mark the delegation in the parent and child zones
be carefully synchronized to minimize the possibility
resolvers become confused
For example, suppose that we wish to create a new zone
ISI.EDU under an existing EDU zone, and that the servers for
child zone are X.ISI.EDU and Y.GOV
We might add the following to the parent zone
ISI.EDU. 10000 NS X.ISI.EDU.
10000 NS Y.GOV.
X.ISI.EDU. 10000 A
Y.GOV. 10000 A
and the following to the child zone
ISI.EDU. 10000 NS X.ISI.EDU.
10000 NS Y.GOV.
50000 SOA information>
X.ISI.EDU. 10000 A
Y.GOV. 10000 A
Note the following
In both cases, the A RR for Y.GOV is included, even
Y.GOV isn't in the EDU or ISI.EDU domains. This RR isn'
authoritative, but is included to guarantee that the address
Y.GOV is passed with delegations to it. Strictly speaking
RR need not be in either zone, but its presence is recommended
The X.ISI.EDU A RR is absolutely essential. The only time
a server should use the glue RRs is when it is returning the
RRs and doesn't otherwise have the address of the server.
example, if the parent server also was authoritative for GOV
the glue RR would typically not be consulted. However, it
still a good idea for it to be present, so that the zone
self-sufficient
Mockapetris [Page 6]
RFC 973 January 1986
Domain System Changes and
The child zone and the parent zone have identical NS RRs
the ISI.EDU domain. This guarantees that no matter
server is asked about the ISI.EDU domain, the same set of
servers is returned
The child zone and the parent zone have A RRs for the
servers in the NS RRs that delegate the ISI.EDU domain.
guarantees that in addition to knowing the name servers for
ISI.EDU domain, the addresses of the servers are known as well
The TTLs for the NS RRs that delegate the ISI.EDU domain
the A RRs that represent the addresses of the name servers
all the same. This guarantees that all of these RRs
timeout simultaneously. In this example, the value 10000
no special significance, but the coincidence of the TTLs
significant
These guidelines haven't changed any of the flexibility of
system; the name of a name server and the domains it serves
still independent
It might also be the case that the organization called ISI
to take over management of the IN-ADDR domain for an
network, say 128.99.0.0. In this case, we would have additions
the parent zone, say IN-ADDR.ARPA
We might add the following to the parent zone
99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
2000 NS XX.MIT.EDU.
Q.ISI.EDU. 2000 A
XX.MIT.EDU. 2000 A
and the following to the child zone
99.128.IN-ADDR.ARPA. 2000 NS Q.ISI.EDU.
2000 NS XX.MIT.EDU.
5000 SOA information>
Q.ISI.EDU. 2000 A
XX.MIT.EDU. 2000 A
SOA
The serial field of the SOA RR for a domain is supposed to be
continuously increasing (mod 2**32) value which denotes
Mockapetris [Page 7]
RFC 973 January 1986
Domain System Changes and
version of the database. The idea is that you can tell that
zone has changed by comparing serial numbers. When you change
zone, you should increment the serial field of the SOA
All RRs with the same name, class, and type should have the same TTL
The logic here is that all of them will timeout simultaneously
cached and hence the cache can be reliably used
Case
The domain system is supposed to preserve case, but be
insensitive. However, it does nobody any good to put both RRs
domain name xxx and XXX in the data base - It merely makes
ambiguous and decreases the efficiency of compression.
consistency should also exist in the duplicate RRs that
delegation in the delegator and delegatee. For example, if
ask the NIC to delegate UZOO.EDU to you, your database shouldn'
say uzoo.edu
Inappropriate use of
Canonical names are preferred to aliases in all RRs. One
is that the canonical names are closer to the
associated with a name. A second is that canonical names
unique, and aliases are not, and hence comparisons will work
In particular, the use of aliases in PTR RRs of the IN-ADDR
or in NS RRs that mark delegation is discouraged
This section discusses some unusual situations and common bugs
are encountered in the present system, and should be helpful
problem determination and tuning. Put differently, you should try
make your code defend against these attacks, and you should expect
be the object of complaint if you make these attacks
UDP
When you send a query to a host with multiple addresses, you
expect the response to be from the address to which you sent
query. This isn't the case with almost all UNIX implementations
Mockapetris [Page 8]
RFC 973 January 1986
Domain System Changes and
UDP
Many versions of UNIX generate incorrect UDP checksums, and
ignore the checksum of incoming UDP datagrams. The
symptom is that your UNIX domain code works fine with
UNIXes, but won't communicate with TOPS-20 or other systems
(JEEVES, the TOPS-20 server used for 3 of the 4 root servers
ignores datagrams with bad UDP checksums.)
Making up
There are lots of name servers which return RRs for the
servers with 99999999 or similar large values in the TTL.
example, some return RRs that suggest that ISIF is a root server
(It was months ago, but is no longer.)
One of the main ideas of the domain system is that everybody
get a chunk of the name space to manage as they choose. However
you aren't supposed to lie about other parts of the name space
Its OK to remember about other parts of the name space for
or other purposes, but you are supposed to follow the TTL rules
Now it may be that you put such records in your server or
to ensure a server of last resort. That's fine. But if
export these in answers to queries, you should be shot.
entries get put in caches and never die
Suggested domain meta-rule
If you must lie, lie only to yourself
PROBLEM
This section discusses some shortcomings in the present system
may be addressed in future versions
Compression and
The present specification attempts to allow name servers
resolvers to cache RRs for classes they don't "understand" as
as to allow compression of domain names to minimize the size
UDP datagrams. These two goals conflict in the present
since the only way to expand a compressed name is to know that
name is expected in that position
One technique for addressing this problem would be to
binary data (i.e. anything but a domain name) with a length octet
Mockapetris [Page 9]
RFC 973 January 1986
Domain System Changes and
The high order two bits of the length octet could contain
01 or 10, which are illegal for domain names. To compensate
the additional bytes of data, we could omit the RDATA length
and terminate each RR with a binary length field of zero
Caching non-existent
In the present system, a resolver has no standard method
caching the result that a name does not exist, which seems to
up a larger than expected percentage of queries. Some
create "does not exist" RRs with TTLs to guarantee
repetitive queries for a non-existent name
A standard technique might be to return the SOA RR for the
(note that only authoritative servers can say name does not exist
in the reply, and define the semantics to be that the requester
free to assume that the name does not exist for a period equal
the MINIMUM field of the SOA
Cache
When a resolver is processing a reply, it may well decide to
all RRs found in sections of the reply. The problem is that
resolver's cache may already contain a subset of these RRs
probably with different TTLs
If the RRs are from authoritative data in the answer section,
the cache RRs should be replaced. In other cases, the
strategy isn't completely clear. Note that if the
data's TTL has changed, then the resolver doesn't have
information to make the correct decision in all cases
This issue is tricky, and deserves thought
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC-882, USC Information Sciences Institute, November 1983.
[2] Mockapetris, P., "Domain Names - Implementation
Specification", RFC-883, USC Information Sciences Institute
November 1983.
[3] Partridge, C., "Mail Routing and the Domain System", RFC-974,
CSNET-CIC, BBN Laboratories, January 1986.
Mockapetris [Page 10]
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
