From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc973.txt | 570 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 570 insertions(+) create mode 100644 doc/rfc/rfc973.txt (limited to 'doc/rfc/rfc973.txt') diff --git a/doc/rfc/rfc973.txt b/doc/rfc/rfc973.txt new file mode 100644 index 0000000..17776f3 --- /dev/null +++ b/doc/rfc/rfc973.txt @@ -0,0 +1,570 @@ + + +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.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 + 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 the + 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 whose + 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 at + ISI.ARPA, look at *.ISI.ARPA. The same thing holds for + Y.ISI.ARPA, or any name of the form .Z.ISI.ARPA, where Z + is a label that doesn't exist under ISI.ARPA) + + Note that this interpretation means that * matches names that are + not in the tree, no matter how much of the tree is missing, and + also matches one level's worth of known tree. + + AA semantics + + When a name server is responding to a query for a particular name + and finds a CNAME, it may optionally restart the search at the + canonical name. If the server uses the restart feature, the + answer section of the returned query contains one (or more) + CNAMEs, possibly followed by answers for the primary name. The + canonical name will usually be in the same zone as the alias, but + this need not be the case. If the server is authoritative for one + of the names but not both, it is not clear whether the AA bit + should be set. + + The solution adopted is to make the AA refer to the original query + name. + + + + + + + +Mockapetris [Page 3] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + Master file format + + The present specification uses a somewhat awkward method for + representing domain names in master files. + + The change adopted is that all domain names in this file will be + represented as either absolute or relative. An absolute domain + name ends with a ".". A free standing "." is assumed to refer to + the root. A relative domain name doesn't end with a dot, and is + assumed to be relative to the current origin. + + SERIAL number size + + If the master file changes rapidly, an infrequently updated copy + may miss the wrapping of the sequence number in the SERIAL field + of the SOA, or misinterpret the number of updates that have taken + place. + + The SERIAL field is increased to 32 bits. + + MD and MF replaced by MX + + The original specification uses MD and MF RRs for mail agent + binding. The problem is that a mailer making a MAILA query, which + asks for both types, can't use the cache since the cache might + have the results for a MD or MF query. That is, the presence of + one of these types of information in the cache doesn't imply + anything about the other type. The result was that either mailers + would have to always consult authoritative servers or try to use + partial information; neither of these is really acceptable. + + The change is to replace MD and MF with a new type of RR called MX + which conveys similar information in a single RR type. MX has + been assigned a type code of 15 decimal. The format of the MX RR + is a 16 bit preference value followed by a domain name. A node + may have multiple MX RRs, and multiple MX RRs with the same + preference value are allowed at a given node. + + + + + + + + + + + + +Mockapetris [Page 4] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + The preference values denote the relative preference that the mail + destination places on the mail agents, with lower values being + "better". A mailer is expected to at least try the mail agent(s) + with the lowest preference value. The significance of particular + preference values, the units of preference, and the linearity of + preference values are not defined but left open; preference values + 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. A + detailed discussion of the use of MX is the subject of [3]. + + Zone transfer + + The original specification states that zone transfers take place + in breadth first order. The intent was to make the transfer + easier for the accepting name server to handle. This now doesn't + work out to be very helpful, and is a severe pain for implementers + using various hashing algorithms. The new rule is that you can + transmit the records in any order you choose, so long as the SOA + node of the zone is transmitted first and last, and no other + duplication occurs. + + IN-ADDR domain renamed + + The name of the IN-ADDR domain is now IN-ADDR.ARPA. This change + was made because many felt that the use of a top-level name was + inappropriate to network-specific information. + + + + + + + + + + +Mockapetris [Page 5] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + +OPERATIONAL GUIDELINES + + This section 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. + + Zone delegation + + When a domain wishes to become independent from its parent, the + RRs which mark the delegation in the parent and child zones should + be carefully synchronized to minimize the possibility that + resolvers become confused. + + For example, suppose that we wish to create a new zone called + ISI.EDU under an existing EDU zone, and that the servers for the + 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 + X.ISI.EDU. 10000 A
+ Y.GOV. 10000 A
+ + Note the following: + + In both cases, the A RR for Y.GOV is included, even though + Y.GOV isn't in the EDU or ISI.EDU domains. This RR isn't + authoritative, but is included to guarantee that the address of + Y.GOV is passed with delegations to it. Strictly speaking this + RR need not be in either zone, but its presence is recommended. + The X.ISI.EDU A RR is absolutely essential. The only time that + a server should use the glue RRs is when it is returning the NS + RRs and doesn't otherwise have the address of the server. For + example, if the parent server also was authoritative for GOV, + the glue RR would typically not be consulted. However, it is + still a good idea for it to be present, so that the zone is + self-sufficient. + + + +Mockapetris [Page 6] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + The child zone and the parent zone have identical NS RRs for + the ISI.EDU domain. This guarantees that no matter which + server is asked about the ISI.EDU domain, the same set of name + servers is returned. + + The child zone and the parent zone have A RRs for the name + servers in the NS RRs that delegate the ISI.EDU domain. This + guarantees that in addition to knowing the name servers for the + ISI.EDU domain, the addresses of the servers are known as well. + + The TTLs for the NS RRs that delegate the ISI.EDU domain and + the A RRs that represent the addresses of the name servers are + all the same. This guarantees that all of these RRs will + timeout simultaneously. In this example, the value 10000 has + no special significance, but the coincidence of the TTLs is + significant. + + These guidelines haven't changed any of the flexibility of the + system; the name of a name server and the domains it serves are + still independent. + + It might also be the case that the organization called ISI wanted + to take over management of the IN-ADDR domain for an internal + network, say 128.99.0.0. In this case, we would have additions to + 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 + Q.ISI.EDU. 2000 A
+ XX.MIT.EDU. 2000 A
+ + SOA serials + + The serial field of the SOA RR for a domain is supposed to be a + continuously increasing (mod 2**32) value which denotes the + + + + +Mockapetris [Page 7] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + version of the database. The idea is that you can tell that a + zone has changed by comparing serial numbers. When you change a + 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 if + cached and hence the cache can be reliably used. + + Case consistency + + The domain system is supposed to preserve case, but be case + insensitive. However, it does nobody any good to put both RRs for + domain name xxx and XXX in the data base - It merely makes caching + ambiguous and decreases the efficiency of compression. This + consistency should also exist in the duplicate RRs that mark + delegation in the delegator and delegatee. For example, if you + ask the NIC to delegate UZOO.EDU to you, your database shouldn't + say uzoo.edu. + + Inappropriate use of aliases + + Canonical names are preferred to aliases in all RRs. One reason + is that the canonical names are closer to the information + associated with a name. A second is that canonical names are + unique, and aliases are not, and hence comparisons will work. + + In particular, the use of aliases in PTR RRs of the IN-ADDR domain + or in NS RRs that mark delegation is discouraged. + +EXPERIENCES + + This section discusses some unusual situations and common bugs which + are encountered in the present system, and should be helpful in + problem determination and tuning. Put differently, you should try to + make your code defend against these attacks, and you should expect to + be the object of complaint if you make these attacks. + + UDP addresses + + When you send a query to a host with multiple addresses, you might + expect the response to be from the address to which you sent the + query. This isn't the case with almost all UNIX implementations. + + + + + + +Mockapetris [Page 8] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + UDP checksums + + Many versions of UNIX generate incorrect UDP checksums, and most + ignore the checksum of incoming UDP datagrams. The typical + symptom is that your UNIX domain code works fine with other + 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 data + + There are lots of name servers which return RRs for the root + servers with 99999999 or similar large values in the TTL. For + 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 can + 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 caching + 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 whatever + to ensure a server of last resort. That's fine. But if you + export these in answers to queries, you should be shot. These + entries get put in caches and never die. + + Suggested domain meta-rule: + + If you must lie, lie only to yourself. + +PROBLEM AREAS + + This section discusses some shortcomings in the present system which + may be addressed in future versions. + + Compression and types + + The present specification attempts to allow name servers and + resolvers to cache RRs for classes they don't "understand" as well + as to allow compression of domain names to minimize the size of + UDP datagrams. These two goals conflict in the present scheme + since the only way to expand a compressed name is to know that a + name is expected in that position. + + One technique for addressing this problem would be to preface + binary data (i.e. anything but a domain name) with a length octet. + + +Mockapetris [Page 9] + + + +RFC 973 January 1986 +Domain System Changes and Observations + + + The high order two bits of the length octet could contain either + 01 or 10, which are illegal for domain names. To compensate for + the additional bytes of data, we could omit the RDATA length field + and terminate each RR with a binary length field of zero. + + Caching non-existent names + + In the present system, a resolver has no standard method for + caching the result that a name does not exist, which seems to make + up a larger than expected percentage of queries. Some resolvers + create "does not exist" RRs with TTLs to guarantee against + repetitive queries for a non-existent name. + + A standard technique might be to return the SOA RR for the zone + (note that only authoritative servers can say name does not exist) + in the reply, and define the semantics to be that the requester is + free to assume that the name does not exist for a period equal to + the MINIMUM field of the SOA. + + Cache conflicts + + When a resolver is processing a reply, it may well decide to cache + all RRs found in sections of the reply. The problem is that the + 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, then + the cache RRs should be replaced. In other cases, the correct + strategy isn't completely clear. Note that if the authoritative + data's TTL has changed, then the resolver doesn't have enough + information to make the correct decision in all cases. + + This issue is tricky, and deserves thought. + +REFERENCES + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC-882, USC Information Sciences Institute, November 1983. + + [2] Mockapetris, P., "Domain Names - Implementation and + 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] + -- cgit v1.2.3