1 Network Working Group                                     P. Mockapetris   
    2 Request for Comments: 1034                                           ISI   
    3 Obsoletes: RFCs 882, 883, 973                              November 1987   
    6                  DOMAIN NAMES - CONCEPTS AND FACILITIES                    
   10 1. STATUS OF THIS MEMO                                                     
   12 This RFC is an introduction to the Domain Name System (DNS), and omits     
   13 many details which can be found in a companion RFC, "Domain Names -        
   14 Implementation and Specification" [RFC-1035].  That RFC assumes that the   
   15 reader is familiar with the concepts discussed in this memo.               
   17 A subset of DNS functions and data types constitute an official            
   18 protocol.  The official protocol includes standard queries and their       
   19 responses and most of the Internet class data formats (e.g., host          
   20 addresses).                                                                
   22 However, the domain system is intentionally extensible.  Researchers are   
   23 continuously proposing, implementing and experimenting with new data       
   24 types, query types, classes, functions, etc.  Thus while the components    
   25 of the official protocol are expected to stay essentially unchanged and    
   26 operate as a production service, experimental behavior should always be    
   27 expected in extensions beyond the official protocol.  Experimental or      
   28 obsolete features are clearly marked in these RFCs, and such information   
   29 should be used with caution.                                               
   31 The reader is especially cautioned not to depend on the values which       
   32 appear in examples to be current or complete, since their purpose is       
   33 primarily pedagogical.  Distribution of this memo is unlimited.            
   35 2. INTRODUCTION                                                            
   37 This RFC introduces domain style names, their use for Internet mail and    
   38 host address support, and the protocols and servers used to implement      
   39 domain name facilities.                                                    
   41 2.1. The history of domain names                                           
   43 The impetus for the development of the domain system was growth in the     
   44 Internet:                                                                  
   46    - Host name to address mappings were maintained by the Network          
   47      Information Center (NIC) in a single file (HOSTS.TXT) which           
   48      was FTPed by all hosts [RFC-952, RFC-953].  The total network         
   52 Mockapetris                                                     [Page 1]   

   53 RFC 1034             Domain Concepts and Facilities        November 1987   
   56      bandwidth consumed in distributing a new version by this              
   57      scheme is proportional to the square of the number of hosts in        
   58      the network, and even when multiple levels of FTP are used,           
   59      the outgoing FTP load on the NIC host is considerable.                
   60      Explosive growth in the number of hosts didn't bode well for          
   61      the future.                                                           
   63    - The network population was also changing in character.  The           
   64      timeshared hosts that made up the original ARPANET were being         
   65      replaced with local networks of workstations.  Local                  
   66      organizations were administering their own names and                  
   67      addresses, but had to wait for the NIC to change HOSTS.TXT to         
   68      make changes visible to the Internet at large.  Organizations         
   69      also wanted some local structure on the name space.                   
   71    - The applications on the Internet were getting more                    
   72      sophisticated and creating a need for general purpose name            
   73      service.                                                              
   76 The result was several ideas about name spaces and their management        
   77 [IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a         
   78 common thread was the idea of a hierarchical name space, with the          
   79 hierarchy roughly corresponding to organizational structure, and names     
   80 using "."  as the character to mark the boundary between hierarchy         
   81 levels.  A design using a distributed database and generalized resources   
   82 was described in [RFC-882, RFC-883].  Based on experience with several     
   83 implementations, the system evolved into the scheme described in this      
   84 memo.                                                                      
   86 The terms "domain" or "domain name" are used in many contexts beyond the   
   87 DNS described here.  Very often, the term domain name is used to refer     
   88 to a name with structure indicated by dots, but no relation to the DNS.    
   89 This is particularly true in mail addressing [Quarterman 86].              
   91 2.2. DNS design goals                                                      
   93 The design goals of the DNS influence its structure.  They are:            
   95    - The primary goal is a consistent name space which will be used        
   96      for referring to resources.  In order to avoid the problems           
   97      caused by ad hoc encodings, names should not be required to           
   98      contain network identifiers, addresses, routes, or similar            
   99      information as part of the name.                                      
  101    - The sheer size of the database and frequency of updates               
  102      suggest that it must be maintained in a distributed manner,           
  103      with local caching to improve performance.  Approaches that           
  107 Mockapetris                                                     [Page 2]   

  108 RFC 1034             Domain Concepts and Facilities        November 1987   
  111      attempt to collect a consistent copy of the entire database           
  112      will become more and more expensive and difficult, and hence          
  113      should be avoided.  The same principle holds for the structure        
  114      of the name space, and in particular mechanisms for creating          
  115      and deleting names; these should also be distributed.                 

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

GLOBAL Stephan Garland(Editorial Erratum #7111) [Verified]
based on outdated version

It should say:

Section 3.6.2 uses both ensure and insure to mean the same thing, which
is to guarantee or make certain. Sections 4.1, 4.2.2, and 5.3.3 all use
the insure form.

Generally, insure is used in the financial sense, with making certain
being a secondary definition. At the very least, consistency in the same
paragraph of 3.6.2 would be cleaner.
GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

This RFC is implemented in BIND 9.18 (all versions).

Many of the RFCs that are listed as updating RFC 1034 actually just mention it, but don't actually update anything here. For example, many of them simply define new RRtypes, which is not really an update to RFC 1034, just to the IANA registry it created. The RFCs that do update RFC 1034 are listed throughout this document.

  117    - Where there tradeoffs between the cost of acquiring data, the         
  118      speed of updates, and the accuracy of caches, the source of           
  119      the data should control the tradeoff.                                 
  121    - The costs of implementing such a facility dictate that it be          
  122      generally useful, and not restricted to a single application.         
  123      We should be able to use names to retrieve host addresses,            
  124      mailbox data, and other as yet undetermined information.  All         
  125      data associated with a name is tagged with a type, and queries        
  126      can be limited to a single type.                                      
  128    - Because we want the name space to be useful in dissimilar             
  129      networks and applications, we provide the ability to use the          
  130      same name space with different protocol families or                   
  131      management.  For example, host address formats differ between         
  132      protocols, though all protocols have the notion of address.           
  133      The DNS tags all data with a class as well as the type, so            
  134      that we can allow parallel use of different formats for data          
  135      of type address.                                                      
  137    - We want name server transactions to be independent of the             
  138      communications system that carries them.  Some systems may            
  139      wish to use datagrams for queries and responses, and only             
  140      establish virtual circuits for transactions that need the             
  141      reliability (e.g., database updates, long transactions); other        
  142      systems will use virtual circuits exclusively.                        
  144    - The system should be useful across a wide spectrum of host            
  145      capabilities.  Both personal computers and large timeshared           
  146      hosts should be able to use the system, though perhaps in             
  147      different ways.                                                       
line-117 John Kristoff(Editorial Erratum #1074) [Verified]
based on outdated version
Section 2.2 says:
  - Where there tradeoffs between the cost of acquiring data, the
It should say:
  - Where there are tradeoffs between the cost of acquiring data, the
  149 2.3. Assumptions about usage                                               
  151 The organization of the domain system derives from some assumptions        
  152 about the needs and usage patterns of its user community and is designed   
  153 to avoid many of the the complicated problems found in general purpose     
  154 database systems.                                                          
  156 The assumptions are:                                                       
  158    - The size of the total database will initially be proportional         
  162 Mockapetris                                                     [Page 3]   

  163 RFC 1034             Domain Concepts and Facilities        November 1987   
  166      to the number of hosts using the system, but will eventually          
  167      grow to be proportional to the number of users on those hosts         
  168      as mailboxes and other information are added to the domain            
  169      system.                                                               
  171    - Most of the data in the system will change very slowly (e.g.,         
  172      mailbox bindings, host addresses), but that the system should         
  173      be able to deal with subsets that change more rapidly (on the         
  174      order of seconds or minutes).                                         
  176    - The administrative boundaries used to distribute                      
  177      responsibility for the database will usually correspond to            
  178      organizations that have one or more hosts.  Each organization         
  179      that has responsibility for a particular set of domains will          
  180      provide redundant name servers, either on the organization's          
  181      own hosts or other hosts that the organization arranges to            
  182      use.                                                                  
  184    - Clients of the domain system should be able to identify               
  185      trusted name servers they prefer to use before accepting              
  186      referrals to name servers outside of this "trusted" set.              
  188    - Access to information is more critical than instantaneous             
  189      updates or guarantees of consistency.  Hence the update               
  190      process allows updates to percolate out through the users of          
  191      the domain system rather than guaranteeing that all copies are        
  192      simultaneously updated.  When updates are unavailable due to          
  193      network or host failure, the usual course is to believe old           
  194      information while continuing efforts to update it.  The               
  195      general model is that copies are distributed with timeouts for        
  196      refreshing.  The distributor sets the timeout value and the           
  197      recipient of the distribution is responsible for performing           
  198      the refresh.  In special situations, very short intervals can         
  199      be specified, or the owner can prohibit copies.                       
  201    - In any system that has a distributed database, a particular           
  202      name server may be presented with a query that can only be            
  203      answered by some other server.  The two general approaches to         
  204      dealing with this problem are "recursive", in which the first         
  205      server pursues the query for the client at another server, and        
  206      "iterative", in which the server refers the client to another         
  207      server and lets the client pursue the query.  Both approaches         
  208      have advantages and disadvantages, but the iterative approach         
  209      is preferred for the datagram style of access.  The domain            
  210      system requires implementation of the iterative approach, but         
  211      allows the recursive approach as an option.                           
  217 Mockapetris                                                     [Page 4]   

  218 RFC 1034             Domain Concepts and Facilities        November 1987   
  221 The domain system assumes that all data originates in master files         
  222 scattered through the hosts that use the domain system.  These master      
  223 files are updated by local system administrators.  Master files are text   
  224 files that are read by a local name server, and hence become available     
  225 through the name servers to users of the domain system.  The user          
  226 programs access name servers through standard programs called resolvers.   
  228 The standard format of master files allows them to be exchanged between    
  229 hosts (via FTP, mail, or some other mechanism); this facility is useful    
  230 when an organization wants a domain, but doesn't want to support a name    
  231 server.  The organization can maintain the master files locally using a    
  232 text editor, transfer them to a foreign host which runs a name server,     
  233 and then arrange with the system administrator of the name server to get   
  234 the files loaded.                                                          
  236 Each host's name servers and resolvers are configured by a local system    
  237 administrator [RFC-1033].  For a name server, this configuration data      
  238 includes the identity of local master files and instructions on which      
  239 non-local master files are to be loaded from foreign servers.  The name    
  240 server uses the master files or copies to load its zones.  For             
  241 resolvers, the configuration data identifies the name servers which        
  242 should be the primary sources of information.                              
  244 The domain system defines procedures for accessing the data and for        
  245 referrals to other name servers.  The domain system also defines           
  246 procedures for caching retrieved data and for periodic refreshing of       
  247 data defined by the system administrator.                                  
  249 The system administrators provide:                                         
  251    - The definition of zone boundaries.                                    
  253    - Master files of data.                                                 
  255    - Updates to master files.                                              
  257    - Statements of the refresh policies desired.                           
  259 The domain system provides:                                                
  261    - Standard formats for resource data.                                   
  263    - Standard methods for querying the database.                           
  265    - Standard methods for name servers to refresh local data from          
  266      foreign name servers.                                                 
  272 Mockapetris                                                     [Page 5]   

  273 RFC 1034             Domain Concepts and Facilities        November 1987   
  276 2.4. Elements of the DNS                                                   
  278 The DNS has three major components:                                        
  280    - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are                 
  281      specifications for a tree structured name space and data              
  282      associated with the names.  Conceptually, each node and leaf          
  283      of the domain name space tree names a set of information, and         
  284      query operations are attempts to extract specific types of            
  285      information from a particular set.  A query names the domain          
  286      name of interest and describes the type of resource                   
  287      information that is desired.  For example, the Internet               
  288      uses some of its domain names to identify hosts; queries for          
  289      address resources return Internet host addresses.                     
  291    - NAME SERVERS are server programs which hold information about         
  292      the domain tree's structure and set information.  A name              
  293      server may cache structure or set information about any part          
  294      of the domain tree, but in general a particular name server           
  295      has complete information about a subset of the domain space,          
  296      and pointers to other name servers that can be used to lead to        
  297      information from any part of the domain tree.  Name servers           
  298      know the parts of the domain tree for which they have complete        
  299      information; a name server is said to be an AUTHORITY for             
  300      these parts of the name space.  Authoritative information is          
  301      organized into units called ZONEs, and these zones can be             
  302      automatically distributed to the name servers which provide           
  303      redundant service for the data in a zone.                             
  305    - RESOLVERS are programs that extract information from name             
  306      servers in response to client requests.  Resolvers must be            
  307      able to access at least one name server and use that name             
  308      server's information to answer a query directly, or pursue the        
  309      query using referrals to other name servers.  A resolver will         
  310      typically be a system routine that is directly accessible to          
  311      user programs; hence no protocol is necessary between the             
  312      resolver and the user program.                                        
  314 These three components roughly correspond to the three layers or views     
  315 of the domain system:                                                      
  317    - From the user's point of view, the domain system is accessed          
  318      through a simple procedure or OS call to a local resolver.            
  319      The domain space consists of a single tree and the user can           
  320      request information from any section of the tree.                     
  322    - From the resolver's point of view, the domain system is               
  323      composed of an unknown number of name servers.  Each name             
  327 Mockapetris                                                     [Page 6]   

  328 RFC 1034             Domain Concepts and Facilities        November 1987   
  331      server has one or more pieces of the whole domain tree's data,        
  332      but the resolver views each of these databases as essentially         
  333      static.                                                               
  335    - From a name server's point of view, the domain system consists        
  336      of separate sets of local information called zones.  The name         
  337      server has local copies of some of the zones.  The name server        
  338      must periodically refresh its zones from master copies in             
  339      local files or foreign name servers.  The name server must            
  340      concurrently process queries that arrive from resolvers.              
section-2.3 Jean-Philippe Paradis(Editorial Erratum #4269) [Held for Document Update]
based on outdated version
The organization of the domain system derives from some assumptions
about the needs and usage patterns of its user community and is designed
to avoid many of the the complicated problems found in general purpose
database systems.
It should say:
The organization of the domain system derives from some assumptions
about the needs and usage patterns of its user community and is designed
to avoid many of the complicated problems found in general purpose
database systems.

Just a duplicate "the".
  342 In the interests of performance, implementations may couple these          
  343 functions.  For example, a resolver on the same machine as a name server   
  344 might share a database consisting of the the zones managed by the name     
  345 server and the cache managed by the resolver.                              
  347 3. DOMAIN NAME SPACE and RESOURCE RECORDS                                  
line-342 Jean-Philippe Paradis(Editorial Erratum #4270) [Held for Document Update]
based on outdated version
In the interests of performance, implementations may couple these
functions.  For example, a resolver on the same machine as a name server
might share a database consisting of the the zones managed by the name
server and the cache managed by the resolver.
It should say:
In the interests of performance, implementations may couple these
functions.  For example, a resolver on the same machine as a name server
might share a database consisting of the the zones managed by the name
server and the cache managed by the resolver.

Just a duplicate "the".
  349 3.1. Name space specifications and terminology                             
  351 The domain name space is a tree structure.  Each node and leaf on the      
  352 tree corresponds to a resource set (which may be empty).  The domain       
  353 system makes no distinctions between the uses of the interior nodes and    
  354 leaves, and this memo uses the term "node" to refer to both.               
  356 Each node has a label, which is zero to 63 octets in length.  Brother      
  357 nodes may not have the same label, although the same label can be used     
  358 for nodes which are not brothers.  One label is reserved, and that is      
  359 the null (i.e., zero length) label used for the root.                      
  361 The domain name of a node is the list of the labels on the path from the   
  362 node to the root of the tree.  By convention, the labels that compose a    
  363 domain name are printed or read left to right, from the most specific      
  364 (lowest, farthest from the root) to the least specific (highest, closest   
  365 to the root).                                                              
  367 Internally, programs that manipulate domain names should represent them    
  368 as sequences of labels, where each label is a length octet followed by     
  369 an octet string.  Because all domain names end at the root, which has a    
  370 null string for a label, these internal representations can use a length   
  371 byte of zero to terminate a domain name.                                   

RFC8020 extensively describes how zone cuts are determined, particularly in the presence of empty non-terminals. It says "This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist."

Section 3.1 of RFC 8020 says:

This document clarifies possible ambiguities in [RFC1034] that did
not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719])
from nonexistent names, and it refers to subsequent documents that
do.  ENTs are nodes in the DNS that do not have resource record sets
associated with them but have descendant nodes that do.  The correct
response to ENTs is NODATA (i.e., a response code of NOERROR and an
empty answer section).  Additional clarifying language on these
points is provided in Section 7.16 of [RFC2136] and in Sections 2.2.2
and 2.2.3 of [RFC4592].

  373 By convention, domain names can be stored with arbitrary case, but         
  374 domain name comparisons for all present domain functions are done in a     
  375 case-insensitive manner, assuming an ASCII character set, and a high       
  376 order zero bit.  This means that you are free to create a node with        
  377 label "A" or a node with label "a", but not both as brothers; you could    
  378 refer to either using "a" or "A".  When you receive a domain name or       
  382 Mockapetris                                                     [Page 7]   

  383 RFC 1034             Domain Concepts and Facilities        November 1987   
  386 label, you should preserve its case.  The rationale for this choice is     
  387 that we may someday need to add full binary domain names for new           
  388 services; existing services would not be changed.                          
  390 When a user needs to type a domain name, the length of each label is       
  391 omitted and the labels are separated by dots (".").  Since a complete      
  392 domain name ends with the root label, this leads to a printed form which   
  393 ends in a dot.  We use this property to distinguish between:               
  395    - a character string which represents a complete domain name            
  396      (often called "absolute").  For example, "poneria.ISI.EDU."           
  398    - a character string that represents the starting labels of a           
  399      domain name which is incomplete, and should be completed by           
  400      local software using knowledge of the local domain (often             
  401      called "relative").  For example, "poneria" used in the               
  402      ISI.EDU domain.                                                       
  404 Relative names are either taken relative to a well known origin, or to a   
  405 list of domains used as a search list.  Relative names appear mostly at    
  406 the user interface, where their interpretation varies from                 
  407 implementation to implementation, and in master files, where they are      
  408 relative to a single origin domain name.  The most common interpretation   
  409 uses the root "." as either the single origin or as one of the members     
  410 of the search list, so a multi-label relative name is often one where      
  411 the trailing dot has been omitted to save typing.                          
  413 To simplify implementations, the total number of octets that represent a   
  414 domain name (i.e., the sum of all label octets and label lengths) is       
  415 limited to 255.                                                            
  417 A domain is identified by a domain name, and consists of that part of      
  418 the domain name space that is at or below the domain name which            
  419 specifies the domain.  A domain is a subdomain of another domain if it     
  420 is contained within that domain.  This relationship can be tested by       
  421 seeing if the subdomain's name ends with the containing domain's name.     
  422 For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".             
  424 3.2. Administrative guidelines on use                                      
  426 As a matter of policy, the DNS technical specifications do not mandate a   
  427 particular tree structure or rules for selecting labels; its goal is to    
  428 be as general as possible, so that it can be used to build arbitrary       
  429 applications.  In particular, the system was designed so that the name     
  430 space did not have to be organized along the lines of network              
  431 boundaries, name servers, etc.  The rationale for this is not that the     
  432 name space should have no implied semantics, but rather that the choice    
  433 of implied semantics should be left open to be used for the problem at     
  437 Mockapetris                                                     [Page 8]   

  438 RFC 1034             Domain Concepts and Facilities        November 1987   
  441 hand, and that different parts of the tree can have different implied      
  442 semantics.  For example, the IN-ADDR.ARPA domain is organized and          
  443 distributed by network and host address because its role is to translate   
  444 from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-     
  445 1002] are flat because that is appropriate for that application.           
  447 However, there are some guidelines that apply to the "normal" parts of     
  448 the name space used for hosts, mailboxes, etc., that will make the name    
  449 space more uniform, provide for growth, and minimize problems as           
  450 software is converted from the older host table.  The political            
  451 decisions about the top levels of the tree originated in RFC-920.          
  452 Current policy for the top levels is discussed in [RFC-1032].  MILNET      
  453 conversion issues are covered in [RFC-1031].                               
  455 Lower domains which will eventually be broken into multiple zones should   
  456 provide branching at the top of the domain so that the eventual            
  457 decomposition can be done without renaming.  Node labels which use         
  458 special characters, leading digits, etc., are likely to break older        
  459 software which depends on more restrictive choices.                        
  461 3.3. Technical guidelines on use                                           
  463 Before the DNS can be used to hold naming information for some kind of     
  464 object, two needs must be met:                                             
  466    - A convention for mapping between object names and domain              
  467      names.  This describes how information about an object is             
  468      accessed.                                                             
  470    - RR types and data formats for describing the object.                  
  472 These rules can be quite simple or fairly complex.  Very often, the        
  473 designer must take into account existing formats and plan for upward       
  474 compatibility for existing usage.  Multiple mappings or levels of          
  475 mapping may be required.                                                   
  477 For hosts, the mapping depends on the existing syntax for host names       
  478 which is a subset of the usual text representation for domain names,       
  479 together with RR formats for describing host addresses, etc.  Because we   
  480 need a reliable inverse mapping from address to host name, a special       
  481 mapping for addresses into the IN-ADDR.ARPA domain is also defined.        

All of RFC4343 is relevant to any discussion of the case of characters.

  483 For mailboxes, the mapping is slightly more complex.  The usual mail       
  484 address <local-part>@<mail-domain> is mapped into a domain name by         
  485 converting <local-part> into a single label (regardles of dots it          
  486 contains), converting <mail-domain> into a domain name using the usual     
  487 text format for domain names (dots denote label breaks), and               
  488 concatenating the two to form a single domain name.  Thus the mailbox      
  492 Mockapetris                                                     [Page 9]   

  493 RFC 1034             Domain Concepts and Facilities        November 1987   
  496 HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by                 
  497 HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this      
  498 design also must take into account the scheme for mail exchanges [RFC-     
  499 974].                                                                      
  501 The typical user is not concerned with defining these rules, but should    
  502 understand that they usually are the result of numerous compromises        
  503 between desires for upward compatibility with old usage, interactions      
  504 between different object definitions, and the inevitable urge to add new   
  505 features when defining the rules.  The way the DNS is used to support      
  506 some object is often more crucial than the restrictions inherent in the    
  507 DNS.                                                                       
  509 3.4. Example name space                                                    
  511 The following figure shows a part of the current domain name space, and    
  512 is used in many examples in this RFC.  Note that the tree is a very        
  513 small subset of the actual name space.                                     
  515                                    |                                       
  516                                    |                                       
  517              +---------------------+------------------+                    
  518              |                     |                  |                    
  519             MIL                   EDU                ARPA                  
  520              |                     |                  |                    
  521              |                     |                  |                    
  522        +-----+-----+               |     +------+-----+-----+              
  523        |     |     |               |     |      |           |              
  524       BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC             
  525                                    |                                       
  526        +--------+------------------+---------------+--------+              
  527        |        |                  |               |        |              
  528       UCI      MIT                 |              UDEL     YALE            
  529                 |                 ISI                                      
  530                 |                  |                                       
  531             +---+---+              |                                       
  532             |       |              |                                       
  533            LCS  ACHILLES  +--+-----+-----+--------+                        
  534             |             |  |     |     |        |                        
  535             XX            A  C   VAXA  VENERA Mockapetris                  
  537 In this example, the root domain has three immediate subdomains: MIL,      
  538 EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named   
  539 XX.LCS.MIT.EDU.  All of the leaves are also domains.                       
  541 3.5. Preferred name syntax                                                 
  543 The DNS specifications attempt to be as general as possible in the rules   
  547 Mockapetris                                                    [Page 10]   

  548 RFC 1034             Domain Concepts and Facilities        November 1987   
  551 for constructing domain names.  The idea is that the name of any           
  552 existing object can be expressed as a domain name with minimal changes.    
  553 However, when assigning a domain name for an object, the prudent user      
  554 will select a name which satisfies both the rules of the domain system     
  555 and any existing rules for the object, whether these rules are published   
  556 or implied by existing programs.                                           
  558 For example, when naming a mail domain, the user should satisfy both the   
  559 rules of this memo and those in RFC-822.  When creating a new host name,   
  560 the old rules for HOSTS.TXT should be followed.  This avoids problems      
  561 when old software is converted to use domain names.                        
  563 The following syntax will result in fewer problems with many               
  564 applications that use domain names (e.g., mail, TELNET).                   
  566 <domain> ::= <subdomain> | " "                                             
  568 <subdomain> ::= <label> | <subdomain> "." <label>                          
  570 <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]                           
  572 <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>                      
  574 <let-dig-hyp> ::= <let-dig> | "-"                                          
  576 <let-dig> ::= <letter> | <digit>                                           
  578 <letter> ::= any one of the 52 alphabetic characters A through Z in        
  579 upper case and a through z in lower case                                   
  581 <digit> ::= any one of the ten digits 0 through 9                          
line-483 Chlisin(Editorial Erratum #564) [Verified]
based on outdated version
   The usual mail address <­local-part>@<­mail-domain> is mapped into a
   domain name by converting <­local-part> into a single label
   (regardles of dots it contains), converting <­mail-domain> into a
   domain name using the usual text format for domain names (dots
   denote label breaks), and concatenating the two to form a single
   domain name. 
It should say:
   The usual mail address <­local-part>@<­mail-domain> is mapped into a
   domain name by converting <­local-part> into a single label
   (regardless of dots it contains), converting <­mail-domain> into a
   domain name using the usual text format for domain names (dots
   denote label breaks), and concatenating the two to form a single
   domain name.
  583 Note that while upper and lower case letters are allowed in domain         
  584 names, no significance is attached to the case.  That is, two names with   
  585 the same spelling but different case are to be treated as if identical.    
  587 The labels must follow the rules for ARPANET host names.  They must        
  588 start with a letter, end with a letter or digit, and have as interior      
  589 characters only letters, digits, and hyphen.  There are also some          
  590 restrictions on the length.  Labels must be 63 characters or less.         
  592 For example, the following strings identify hosts in the Internet:         
  594 A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA                                    
  596 3.6. Resource Records                                                      
  598 A domain name identifies a node.  Each node has a set of resource          
  602 Mockapetris                                                    [Page 11]   

  603 RFC 1034             Domain Concepts and Facilities        November 1987   
  606 information, which may be empty.  The set of resource information          
  607 associated with a particular name is composed of separate resource         
  608 records (RRs).  The order of RRs in a set is not significant, and need     
  609 not be preserved by name servers, resolvers, or other parts of the DNS.    
  611 When we talk about a specific RR, we assume it has the following:          
  613 owner           which is the domain name where the RR is found.            
  615 type            which is an encoded 16 bit value that specifies the type   
  616                 of the resource in this resource record.  Types refer to   
  617                 abstract resources.                                        
  619                 This memo uses the following types:                        
  621                 A               a host address                             
  623                 CNAME           identifies the canonical name of an        
  624                                 alias                                      
  626                 HINFO           identifies the CPU and OS used by a host   

All of RFC4343 is relevant to any discussion of the case of characters.

  628                 MX              identifies a mail exchange for the         
  629                                 domain.  See [RFC-974 for details.         
  631                 NS                                                         
  632                 the authoritative name server for the domain               
  634                 PTR                                                        
  635                 a pointer to another part of the domain name space         
  637                 SOA                                                        
  638                 identifies the start of a zone of authority]               
  640 class           which is an encoded 16 bit value which identifies a        
  641                 protocol family or instance of a protocol.                 
  643                 This memo uses the following classes:                      
  645                 IN              the Internet system                        
  647                 CH              the Chaos system                           
line-628 Han Ge Xin(Editorial Erratum #4511) [Held for Document Update]
based on outdated version
identifies a mail exchange for the domain. See [RFC-974 for details.
It should say:
identifies a mail exchange for the domain. See [RFC-974] for details.

Just missing the "]"
  649 TTL             which is the time to live of the RR.  This field is a 32   
  650                 bit integer in units of seconds, an is primarily used by   
  651                 resolvers when they cache RRs.  The TTL describes how      
  652                 long a RR can be cached before it should be discarded.     
  657 Mockapetris                                                    [Page 12]   

  658 RFC 1034             Domain Concepts and Facilities        November 1987   
  661 RDATA           which is the type and sometimes class dependent data       
  662                 which describes the resource:                              
  664                 A               For the IN class, a 32 bit IP address      
  666                                 For the CH class, a domain name followed   
  667                                 by a 16 bit octal Chaos address.           
  669                 CNAME           a domain name.                             
  671                 MX              a 16 bit preference value (lower is        
  672                                 better) followed by a host name willing    
  673                                 to act as a mail exchange for the owner    
  674                                 domain.                                    
  676                 NS              a host name.                               
  678                 PTR             a domain name.                             
  680                 SOA             several fields.                            
  682 The owner name is often implicit, rather than forming an integral part     
  683 of the RR.  For example, many name servers internally form tree or hash    
  684 structures for the name space, and chain RRs off nodes.  The remaining     
  685 RR parts are the fixed header (type, class, TTL) which is consistent for   
  686 all RRs, and a variable part (RDATA) that fits the needs of the resource   
  687 being described.                                                           
  689 The meaning of the TTL field is a time limit on how long an RR can be      
  690 kept in a cache.  This limit does not apply to authoritative data in       
  691 zones; it is also timed out, but by the refreshing policies for the        
  692 zone.  The TTL is assigned by the administrator for the zone where the     
  693 data originates.  While short TTLs can be used to minimize caching, and    
  694 a zero TTL prohibits caching, the realities of Internet performance        
  695 suggest that these times should be on the order of days for the typical    
  696 host.  If a change can be anticipated, the TTL can be reduced prior to     
  697 the change to minimize inconsistency during the change, and then           
  698 increased back to its former value following the change.                   
  700 The data in the RDATA section of RRs is carried as a combination of        
  701 binary strings and domain names.  The domain names are frequently used     
  702 as "pointers" to other data in the DNS.                                    
  704 3.6.1. Textual expression of RRs                                           
  706 RRs are represented in binary form in the packets of the DNS protocol,     
  707 and are usually represented in highly encoded form when stored in a name   
  708 server or resolver.  In this memo, we adopt a style similar to that used   
  712 Mockapetris                                                    [Page 13]   

  713 RFC 1034             Domain Concepts and Facilities        November 1987   
  716 in master files in order to show the contents of RRs.  In this format,     
  717 most RRs are shown on a single line, although continuation lines are       
  718 possible using parentheses.                                                
  720 The start of the line gives the owner of the RR.  If a line begins with    
  721 a blank, then the owner is assumed to be the same as that of the           
  722 previous RR.  Blank lines are often included for readability.              
  724 Following the owner, we list the TTL, type, and class of the RR.  Class    
  725 and type use the mnemonics defined above, and TTL is an integer before     
  726 the type field.  In order to avoid ambiguity in parsing, type and class    
  727 mnemonics are disjoint, TTLs are integers, and the type mnemonic is        
  728 always last. The IN class and TTL values are often omitted from examples   
  729 in the interests of clarity.                                               
  731 The resource data or RDATA section of the RR are given using knowledge     
  732 of the typical representation for the data.                                
  734 For example, we might show the RRs carried in a message as:                
  736     ISI.EDU.        MX      10 VENERA.ISI.EDU.                             
  737                     MX      10 VAXA.ISI.EDU.                               
  738     VENERA.ISI.EDU. A                                     
  739                     A                                      
  740     VAXA.ISI.EDU.   A                                      
  741                     A                                     
  743 The MX RRs have an RDATA section which consists of a 16 bit number         
  744 followed by a domain name.  The address RRs use a standard IP address      
  745 format to contain a 32 bit internet address.                               
  747 This example shows six RRs, with two RRs at each of three domain names.    
  749 Similarly we might see:                                                    
  751     XX.LCS.MIT.EDU. IN      A                              
  752                     CH      A       MIT.EDU. 2420                          
  754 This example shows two addresses for XX.LCS.MIT.EDU, each of a different   
  755 class.                                                                     
  757 3.6.2. Aliases and canonical names                                         
  759 In existing systems, hosts and other resources often have several names    
  760 that identify the same resource.  For example, the names C.ISI.EDU and     
  761 USC-ISIC.ARPA both identify the same host.  Similarly, in the case of      
  762 mailboxes, many organizations provide many names that actually go to the   
  763 same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,    
  767 Mockapetris                                                    [Page 14]   

  768 RFC 1034             Domain Concepts and Facilities        November 1987   
  771 and PVM@ISI.EDU all go to the same mailbox (although the mechanism         
  772 behind this is somewhat complicated).                                      
  774 Most of these systems have a notion that one of the equivalent set of      
  775 names is the canonical or primary name and all others are aliases.         
  777 The domain system provides such a feature using the canonical name         
  778 (CNAME) RR.  A CNAME RR identifies its owner name as an alias, and         
  779 specifies the corresponding canonical name in the RDATA section of the     

The abstract of RFC8767 says: "This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data." The reason this updates RFC 1034 is that the definition of TTL in RFC 1034 says "The TTL describes how long a RR can be cached before it should be discarded." RFC 8767 softens that "should" and describes various scenarios when it is acceptable to serve stale data.

  780 RR.  If a CNAME RR is present at a node, no other data should be           
  781 present; this ensures that the data for a canonical name and its aliases   
  782 cannot be different.  This rule also insures that a cached CNAME can be    
  783 used without checking with an authoritative server for other RR types.     
  785 CNAME RRs cause special action in DNS software.  When a name server        
  786 fails to find a desired RR in the resource set associated with the         
  787 domain name, it checks to see if the resource set consists of a CNAME      
  788 record with a matching class.  If so, the name server includes the CNAME   
  789 record in the response and restarts the query at the domain name           
  790 specified in the data field of the CNAME record.  The one exception to     
  791 this rule is that queries which match the CNAME type are not restarted.    

Section 3 of RFC4034 says:

Because every authoritative RRset in a zone must be protected by a
digital signature, RRSIG RRs must be present for names containing a
CNAME RR.  This is a change to the traditional DNS specification
[RFC1034], which stated that if a CNAME is present for a name, it is
the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
MUST exist for the same name as a CNAME resource record in a signed

Similar wording is found in Section 2.5 of RFC4035.

  793 For example, suppose a name server was processing a query with for USC-    
  794 ISIC.ARPA, asking for type A information, and had the following resource   
  795 records:                                                                   
  797     USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU                              
  799     C.ISI.EDU       IN      A                              
  801 Both of these RRs would be returned in the response to the type A query,   
  802 while a type CNAME or * query should return just the CNAME.                
  804 Domain names in RRs which point at another name should always point at     
  805 the primary name and not the alias.  This avoids extra indirections in     
  806 accessing information.  For example, the address to name RR for the        
  807 above host should be:                                                      
  809  IN      PTR     C.ISI.EDU                      
  811 rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness       
  812 principle, domain software should not fail when presented with CNAME       
  813 chains or loops; CNAME chains should be followed and CNAME loops           
  814 signalled as an error.                                                     
line-793 John Kristoff(Editorial Erratum #1074) [Verified]
based on outdated version
Section 3.6.2 says:
  For example, suppose a name server was processing a query with for USC-
It should say:
  For example, suppose a name server was processing a query with for USC-
  816 3.7. Queries                                                               
  818 Queries are messages which may be sent to a name server to provoke a       
  822 Mockapetris                                                    [Page 15]   

  823 RFC 1034             Domain Concepts and Facilities        November 1987   
  826 response.  In the Internet, queries are carried in UDP datagrams or over   
  827 TCP connections.  The response by the name server either answers the       
  828 question posed in the query, refers the requester to another set of name   
  829 servers, or signals some error condition.                                  
  831 In general, the user does not generate queries directly, but instead       
  832 makes a request to a resolver which in turn sends one or more queries to   
  833 name servers and deals with the error conditions and referrals that may    
  834 result.  Of course, the possible questions which can be asked in a query   
  835 does shape the kind of service a resolver can provide.                     
  837 DNS queries and responses are carried in a standard message format.  The   
  838 message format has a header containing a number of fixed fields which      
  839 are always present, and four sections which carry query parameters and     
  840 RRs.                                                                       
  842 The most important field in the header is a four bit field called an       
  843 opcode which separates different queries.  Of the possible 16 values,      
  844 one (standard query) is part of the official protocol, two (inverse        
  845 query and status query) are options, one (completion) is obsolete, and     
  846 the rest are unassigned.                                                   
  848 The four sections are:                                                     
  850 Question        Carries the query name and other query parameters.         
  852 Answer          Carries RRs which directly answer the query.               
  854 Authority       Carries RRs which describe other authoritative servers.    
  855                 May optionally carry the SOA RR for the authoritative      
  856                 data in the answer section.                                
  858 Additional      Carries RRs which may be helpful in using the RRs in the   
  859                 other sections.                                            
  861 Note that the content, but not the format, of these sections varies with   
  862 header opcode.                                                             
  864 3.7.1. Standard queries                                                    
  866 A standard query specifies a target domain name (QNAME), query type        
  867 (QTYPE), and query class (QCLASS) and asks for RRs which match.  This      
  868 type of query makes up such a vast majority of DNS queries that we use     
  869 the term "query" to mean standard query unless otherwise specified.  The   
  870 QTYPE and QCLASS fields are each 16 bits long, and are a superset of       
  871 defined types and classes.                                                 
  877 Mockapetris                                                    [Page 16]   

  878 RFC 1034             Domain Concepts and Facilities        November 1987   
  881 The QTYPE field may contain:                                               
  883 <any type>      matches just that type. (e.g., A, PTR).                    
  885 AXFR            special zone transfer QTYPE.                               
  887 MAILB           matches all mail box related RRs (e.g. MB and MG).         
  889 *               matches all RR types.                                      
  891 The QCLASS field may contain:                                              
  893 <any class>     matches just that class (e.g., IN, CH).                    
  895 *               matches aLL RR classes.                                    
  897 Using the query domain name, QTYPE, and QCLASS, the name server looks      
  898 for matching RRs.  In addition to relevant records, the name server may    
  899 return RRs that point toward a name server that has the desired            
  900 information or RRs that are expected to be useful in interpreting the      
  901 relevant RRs.  For example, a name server that doesn't have the            
  902 requested information may know a name server that does; a name server      
  903 that returns a domain name in a relevant RR may also return the RR that    
  904 binds that domain name to an address.                                      

Section 7.1 of RFC2181 says:

RFC1034, in section 3.7, indicates that the authority section of an
authoritative answer may contain the SOA record for the zone from
which the answer was obtained.  When discussing negative caching,
RFC1034 section 4.3.4 refers to this technique but mentions the
additional section of the response.  The former is correct, as is
implied by the example shown in section 6.2.5 of RFC1034.  SOA
records, if added, are to be placed in the authority section.

  906 For example, a mailer tying to send mail to Mockapetris@ISI.EDU might      
  907 ask the resolver for mail information about ISI.EDU, resulting in a        
  908 query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer       
  909 section would be:                                                          
  911     ISI.EDU.        MX      10 VENERA.ISI.EDU.                             
  912                     MX      10 VAXA.ISI.EDU.                               
  914 while the additional section might be:                                     
  916     VAXA.ISI.EDU.   A                                      
  917                     A                                     
  918     VENERA.ISI.EDU. A                                      
  919                     A                                     
  921 Because the server assumes that if the requester wants mail exchange       
  922 information, it will probably want the addresses of the mail exchanges     
  923 soon afterward.                                                            
  925 Note that the QCLASS=* construct requires special interpretation           
  926 regarding authority.  Since a particular name server may not know all of   
  927 the classes available in the domain system, it can never know if it is     
  928 authoritative for all classes.  Hence responses to QCLASS=* queries can    
  932 Mockapetris                                                    [Page 17]   

  933 RFC 1034             Domain Concepts and Facilities        November 1987   
  936 never be authoritative.                                                    
  938 3.7.2. Inverse queries (Optional)                                          
  940 Name servers may also support inverse queries that map a particular        
  941 resource to a domain name or domain names that have that resource.  For    
  942 example, while a standard query might map a domain name to a SOA RR, the   
  943 corresponding inverse query might map the SOA RR back to the domain        
  944 name.                                                                      
  946 Implementation of this service is optional in a name server, but all       
  947 name servers must at least be able to understand an inverse query          
  948 message and return a not-implemented error response.                       
  950 The domain system cannot guarantee the completeness or uniqueness of       
  951 inverse queries because the domain system is organized by domain name      
  952 rather than by host address or any other resource type.  Inverse queries   
  953 are primarily useful for debugging and database maintenance activities.    
  955 Inverse queries may not return the proper TTL, and do not indicate cases   
  956 where the identified RR is one of a set (for example, one address for a    
  957 host having multiple addresses).  Therefore, the RRs returned in inverse   
  958 queries should never be cached.                                            
  960 Inverse queries are NOT an acceptable method for mapping host addresses    
  961 to host names; use the IN-ADDR.ARPA domain instead.                        
  963 A detailed discussion of inverse queries is contained in [RFC-1035].       
  965 3.8. Status queries (Experimental)                                         
  967 To be defined.                                                             
  969 3.9. Completion queries (Obsolete)                                         
  971 The optional completion services described in RFCs 882 and 883 have been   
  972 deleted.  Redesigned services may become available in the future, or the   
  973 opcodes may be reclaimed for other use.                                    
  975 4. NAME SERVERS                                                            
  977 4.1. Introduction                                                          
  979 Name servers are the repositories of information that make up the domain   
  980 database.  The database is divided up into sections called zones, which    
  981 are distributed among the name servers.  While name servers can have       
  982 several optional functions and sources of data, the essential task of a    
  983 name server is to answer queries using data in its zones.  By design,      
  987 Mockapetris                                                    [Page 18]   

  988 RFC 1034             Domain Concepts and Facilities        November 1987   
  991 name servers can answer queries in a simple manner; the response can       
  992 always be generated using only local data, and either contains the         
  993 answer to the question or a referral to other name servers "closer" to     
  994 the desired information.                                                   
  996 A given zone will be available from several name servers to insure its     
  997 availability in spite of host or communication link failure.  By           
  998 administrative fiat, we require every zone to be available on at least     
  999 two servers, and many zones have more redundancy than that.                
 1001 A given name server will typically support one or more zones, but this     
 1002 gives it authoritative information about only a small section of the       
 1003 domain tree.  It may also have some cached non-authoritative data about    
 1004 other parts of the tree.  The name server marks its responses to queries   
 1005 so that the requester can tell whether the response comes from             
 1006 authoritative data or not.                                                 
 1008 4.2. How the database is divided into zones                                
 1010 The domain database is partitioned in two ways: by class, and by "cuts"    
 1011 made in the name space between nodes.                                      
 1013 The class partition is simple.  The database for any class is organized,   
 1014 delegated, and maintained separately from all other classes.  Since, by    
 1015 convention, the name spaces are the same for all classes, the separate     
 1016 classes can be thought of as an array of parallel namespace trees.  Note   
 1017 that the data attached to nodes will be different for these different      
 1018 parallel classes.  The most common reasons for creating a new class are    
 1019 the necessity for a new data format for existing types or a desire for a   
 1020 separately managed version of the existing name space.                     
 1022 Within a class, "cuts" in the name space can be made between any two       
 1023 adjacent nodes.  After all cuts are made, each group of connected name     
 1024 space is a separate zone.  The zone is said to be authoritative for all    
 1025 names in the connected region.  Note that the "cuts" in the name space     
 1026 may be in different places for different classes, the name servers may     
 1027 be different, etc.                                                         
 1029 These rules mean that every zone has at least one node, and hence domain   
 1030 name, for which it is authoritative, and all of the nodes in a             
 1031 particular zone are connected.  Given, the tree structure, every zone      
 1032 has a highest node which is closer to the root than any other node in      
 1033 the zone.  The name of this node is often used to identify the zone.       
 1035 It would be possible, though not particularly useful, to partition the     
 1036 name space so that each domain name was in a separate zone or so that      
 1037 all nodes were in a single zone.  Instead, the database is partitioned     
 1038 at points where a particular organization wants to take over control of    
 1042 Mockapetris                                                    [Page 19]   

 1043 RFC 1034             Domain Concepts and Facilities        November 1987   
 1046 a subtree.  Once an organization controls its own zone it can              
 1047 unilaterally change the data in the zone, grow new tree sections           
 1048 connected to the zone, delete existing nodes, or delegate new subzones     
 1049 under its zone.                                                            
 1051 If the organization has substructure, it may want to make further          
 1052 internal partitions to achieve nested delegations of name space control.   
 1053 In some cases, such divisions are made purely to make database             
 1054 maintenance more convenient.                                               
 1056 4.2.1. Technical considerations                                            
 1058 The data that describes a zone has four major parts:                       
 1060    - Authoritative data for all nodes within the zone.                     
 1062    - Data that defines the top node of the zone (can be thought of         
 1063      as part of the authoritative data).                                   
 1065    - Data that describes delegated subzones, i.e., cuts around the         
 1066      bottom of the zone.                                                   
 1068    - Data that allows access to name servers for subzones                  
 1069      (sometimes called "glue" data).                                       
 1071 All of this data is expressed in the form of RRs, so a zone can be         
 1072 completely described in terms of a set of RRs.  Whole zones can be         
 1073 transferred between name servers by transferring the RRs, either carried   
 1074 in a series of messages or by FTPing a master file which is a textual      
 1075 representation.                                                            
 1077 The authoritative data for a zone is simply all of the RRs attached to     
 1078 all of the nodes from the top node of the zone down to leaf nodes or       
 1079 nodes above cuts around the bottom edge of the zone.                       
 1081 Though logically part of the authoritative data, the RRs that describe     
 1082 the top node of the zone are especially important to the zone's            
 1083 management.  These RRs are of two types: name server RRs that list, one    
 1084 per RR, all of the servers for the zone, and a single SOA RR that          
 1085 describes zone management parameters.                                      
line-906 anonymous(Editorial Erratum #4893) [Held for Document Update]
based on outdated version
For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a
It should say:
For example, a mailer trying to send mail to Mockapetris@ISI.EDU might
ask the resolver for mail information about ISI.EDU, resulting in a

Trying, not tying.
 1087 The RRs that describe cuts around the bottom of the zone are NS RRs that   
 1088 name the servers for the subzones.  Since the cuts are between nodes,      
 1089 these RRs are NOT part of the authoritative data of the zone, and should   
 1090 be exactly the same as the corresponding RRs in the top node of the        
 1091 subzone.  Since name servers are always associated with zone boundaries,   
 1092 NS RRs are only found at nodes which are the top node of some zone.  In    
 1093 the data that makes up a zone, NS RRs are found at the top node of the     
 1097 Mockapetris                                                    [Page 20]   

 1098 RFC 1034             Domain Concepts and Facilities        November 1987   
 1101 zone (and are authoritative) and at cuts around the bottom of the zone     
 1102 (where they are not authoritative), but never in between.                  
 1104 One of the goals of the zone structure is that any zone have all the       
 1105 data required to set up communications with the name servers for any       
 1106 subzones.  That is, parent zones have all the information needed to        
 1107 access servers for their children zones.  The NS RRs that name the         
 1108 servers for subzones are often not enough for this task since they name    
 1109 the servers, but do not give their addresses.  In particular, if the       
 1110 name of the name server is itself in the subzone, we could be faced with   
 1111 the situation where the NS RRs tell us that in order to learn a name       
 1112 server's address, we should contact the server using the address we wish   
 1113 to learn.  To fix this problem, a zone contains "glue" RRs which are not   
 1114 part of the authoritative data, and are address RRs for the servers.       
 1115 These RRs are only necessary if the name server's name is "below" the      
 1116 cut, and are only used as part of a referral response.                     
 1118 4.2.2. Administrative considerations                                       
 1120 When some organization wants to control its own domain, the first step     
 1121 is to identify the proper parent zone, and get the parent zone's owners    
 1122 to agree to the delegation of control.  While there are no particular      
 1123 technical constraints dealing with where in the tree this can be done,     
 1124 there are some administrative groupings discussed in [RFC-1032] which      
 1125 deal with top level organization, and middle level zones are free to       
 1126 create their own rules.  For example, one university might choose to use   
 1127 a single zone, while another might choose to organize by subzones          

Section 2.6 of RFC4035 says:

DNSSEC introduced two new RR types that are unusual in that they can
appear at the parental side of a zone cut.  At the parental side of a
zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
the owner name.  A DS RR could also be present if the zone being
delegated is signed and seeks to have a chain of authentication to
the parent zone.  This is an exception to the original DNS
specification ([RFC1034]), which states that only NS RRsets could
appear at the parental side of a zone cut.

This specification updates the original DNS specification to allow
NSEC and DS RR types at the parent side of a zone cut.  These RRsets
are authoritative for the parent when they appear at the parent side
of a zone cut.

 1128 dedicated to individual departments or schools.  [RFC-1033] catalogs       
 1129 available DNS software an discusses administration procedures.             
 1131 Once the proper name for the new subzone is selected, the new owners       
 1132 should be required to demonstrate redundant name server support.  Note     
 1133 that there is no requirement that the servers for a zone reside in a       
 1134 host which has a name in that domain.  In many cases, a zone will be       
 1135 more accessible to the internet at large if its servers are widely         
 1136 distributed rather than being within the physical facilities controlled    
 1137 by the same organization that manages the zone.  For example, in the       
 1138 current DNS, one of the name servers for the United Kingdom, or UK         
 1139 domain, is found in the US.  This allows US hosts to get UK data without   
 1140 using limited transatlantic bandwidth.                                     
 1142 As the last installation step, the delegation NS RRs and glue RRs          
 1143 necessary to make the delegation effective should be added to the parent   
 1144 zone.  The administrators of both zones should insure that the NS and      
 1145 glue RRs which mark both sides of the cut are consistent and remain so.    
 1147 4.3. Name server internals                                                 
 1152 Mockapetris                                                    [Page 21]   

 1153 RFC 1034             Domain Concepts and Facilities        November 1987   
 1156 4.3.1. Queries and responses                                               
 1158 The principal activity of name servers is to answer standard queries.      
 1159 Both the query and its response are carried in a standard message format   
 1160 which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,     
 1161 and QNAME, which describe the types and classes of desired information     
 1162 and the name of interest.                                                  
 1164 The way that the name server answers the query depends upon whether it     
 1165 is operating in recursive mode or not:                                     
 1167    - The simplest mode for the server is non-recursive, since it           
 1168      can answer queries using only local information: the response         
 1169      contains an error, the answer, or a referral to some other            
 1170      server "closer" to the answer.  All name servers must                 
 1171      implement non-recursive queries.                                      
 1173    - The simplest mode for the client is recursive, since in this          
 1174      mode the name server acts in the role of a resolver and               
 1175      returns either an error or the answer, but never referrals.           
 1176      This service is optional in a name server, and the name server        
 1177      may also choose to restrict the clients which can use                 
 1178      recursive mode.                                                       
 1180 Recursive service is helpful in several situations:                        
 1182    - a relatively simple requester that lacks the ability to use           
 1183      anything other than a direct answer to the question.                  
 1185    - a request that needs to cross protocol or other boundaries and        
 1186      can be sent to a server which can act as intermediary.                
 1188    - a network where we want to concentrate the cache rather than          
 1189      having a separate cache for each client.                              
 1191 Non-recursive service is appropriate if the requester is capable of        
 1192 pursuing referrals and interested in information which will aid future     
 1193 requests.                                                                  
 1195 The use of recursive mode is limited to cases where both the client and    
 1196 the name server agree to its use.  The agreement is negotiated through     
 1197 the use of two bits in query and response messages:                        
 1199    - The recursion available, or RA bit, is set or cleared by a            
 1200      name server in all responses.  The bit is true if the name            
 1201      server is willing to provide recursive service for the client,        
 1202      regardless of whether the client requested recursive service.         
 1203      That is, RA signals availability rather than use.                     
 1207 Mockapetris                                                    [Page 22]   

 1208 RFC 1034             Domain Concepts and Facilities        November 1987   
line-1128 Sun Congyou(Editorial Erratum #4229) [Held for Document Update]
based on outdated version
[RFC-1033] catalogs available DNS software an discusses administration 
It should say:
[RFC-1033] catalogs available DNS software and discusses administration 
 1211    - Queries contain a bit called recursion desired or RD.  This           
 1212      bit specifies specifies whether the requester wants recursive         
 1213      service for this query.  Clients may request recursive service        
 1214      from any name server, though they should depend upon receiving        
 1215      it only from servers which have previously sent an RA, or             
 1216      servers which have agreed to provide service through private          
 1217      agreement or some other means outside of the DNS protocol.            
 1219 The recursive mode occurs when a query with RD set arrives at a server     
 1220 which is willing to provide recursive service; the client can verify       
 1221 that recursive mode was used by checking that both RA and RD are set in    
 1222 the reply.  Note that the name server should never perform recursive       
 1223 service unless asked via RD, since this interferes with trouble shooting   
 1224 of name servers and their databases.                                       
 1226 If recursive service is requested and available, the recursive response    
 1227 to a query will be one of the following:                                   
 1229    - The answer to the query, possibly preface by one or more CNAME        
 1230      RRs that specify aliases encountered on the way to an answer.         
 1232    - A name error indicating that the name does not exist.  This           
 1233      may include CNAME RRs that indicate that the original query           
 1234      name was an alias for a name which does not exist.                    
 1236    - A temporary error indication.                                         
 1238 If recursive service is not requested or is not available, the non-        
 1239 recursive response will be one of the following:                           
 1241    - An authoritative name error indicating that the name does not         
 1242      exist.                                                                
 1244    - A temporary error indication.                                         
 1246    - Some combination of:                                                  
 1248      RRs that answer the question, together with an indication             
 1249      whether the data comes from a zone or is cached.                      
 1251      A referral to name servers which have zones which are closer          
 1252      ancestors to the name than the server sending the reply.              
 1254    - RRs that the name server thinks will prove useful to the              
 1255      requester.                                                            
 1262 Mockapetris                                                    [Page 23]   

 1263 RFC 1034             Domain Concepts and Facilities        November 1987   
line-1211 "Yin Shuming"(Editorial Erratum #565) [Verified]
based on outdated version
This bit specifies specifies whether the requester wants recursive service 
for this query. Clients may.....
It should say:
This bit specifies specifies whether the requester wants recursive service
for this query. Clients may.....
 1266 4.3.2. Algorithm                                                           
 1268 The actual algorithm used by the name server will depend on the local OS   
 1269 and data structures used to store RRs.  The following algorithm assumes    
 1270 that the RRs are organized in several tree structures, one for each        
 1271 zone, and another for the cache:                                           
 1273    1. Set or clear the value of recursion available in the response        
 1274       depending on whether the name server is willing to provide           
 1275       recursive service.  If recursive service is available and            
 1276       requested via the RD bit in the query, go to step 5,                 
 1277       otherwise step 2.                                                    
 1279    2. Search the available zones for the zone which is the nearest         
 1280       ancestor to QNAME.  If such a zone is found, go to step 3,           
 1281       otherwise step 4.                                                    
 1283    3. Start matching down, label by label, in the zone.  The               
 1284       matching process can terminate several ways:                         
 1286          a. If the whole of QNAME is matched, we have found the            
 1287             node.                                                          
 1289             If the data at the node is a CNAME, and QTYPE doesn't          
 1290             match CNAME, copy the CNAME RR into the answer section         
 1291             of the response, change QNAME to the canonical name in         
 1292             the CNAME RR, and go back to step 1.                           
 1294             Otherwise, copy all RRs which match QTYPE into the             
 1295             answer section and go to step 6.                               
 1297          b. If a match would take us out of the authoritative data,        
 1298             we have a referral.  This happens when we encounter a          
 1299             node with NS RRs marking cuts along the bottom of a            
 1300             zone.                                                          
 1302             Copy the NS RRs for the subzone into the authority             
 1303             section of the reply.  Put whatever addresses are              
 1304             available into the additional section, using glue RRs          
 1305             if the addresses are not available from authoritative          
 1306             data or the cache.  Go to step 4.                              
 1308          c. If at some label, a match is impossible (i.e., the             
 1309             corresponding label does not exist), look to see if a          
 1310             the "*" label exists.                                          
 1312             If the "*" label does not exist, check whether the name        
 1313             we are looking for is the original QNAME in the query          
 1317 Mockapetris                                                    [Page 24]   

 1318 RFC 1034             Domain Concepts and Facilities        November 1987   
 1321             or a name we have followed due to a CNAME.  If the name        
 1322             is original, set an authoritative name error in the            
 1323             response and exit.  Otherwise just exit.                       
 1325             If the "*" label does exist, match RRs at that node            
 1326             against QTYPE.  If any match, copy them into the answer        
 1327             section, but set the owner of the RR to be QNAME, and          
 1328             not the node with the "*" label.  Go to step 6.                
 1330    4. Start matching down in the cache.  If QNAME is found in the          
 1331       cache, copy all RRs attached to it that match QTYPE into the         
 1332       answer section.  If there was no delegation from                     
 1333       authoritative data, look for the best one from the cache, and        
 1334       put it in the authority section.  Go to step 6.                      
 1336    5. Using the local resolver or a copy of its algorithm (see             
 1337       resolver section of this memo) to answer the query.  Store           
 1338       the results, including any intermediate CNAMEs, in the answer        
 1339       section of the response.                                             

RFC8482 gives guidance on what the proper response to and query for type ANY would be. In particular, Section 7 of RFC 8482 updates the processing instructions in RFC 1034 for ANY queries.

 1341    6. Using local data only, attempt to add other RRs which may be         
 1342       useful to the additional section of the query.  Exit.                
 1344 4.3.3. Wildcards                                                           
 1346 In the previous algorithm, special treatment was given to RRs with owner   
 1347 names starting with the label "*".  Such RRs are called wildcards.         
 1348 Wildcard RRs can be thought of as instructions for synthesizing RRs.       
 1349 When the appropriate conditions are met, the name server creates RRs       
 1350 with an owner name equal to the query name and contents taken from the     
 1351 wildcard RRs.                                                              
 1353 This facility is most often used to create a zone which will be used to    
 1354 forward mail from the Internet to some other mail system.  The general     
 1355 idea is that any name in that zone which is presented to server in a       
 1356 query will be assumed to exist, with certain properties, unless explicit   
 1357 evidence exists to the contrary.  Note that the use of the term zone       
 1358 here, instead of domain, is intentional; such defaults do not propagate    
 1359 across zone boundaries, although a subzone may choose to achieve that      
 1360 appearance by setting up similar defaults.                                 
 1362 The contents of the wildcard RRs follows the usual rules and formats for   
 1363 RRs.  The wildcards in the zone have an owner name that controls the       
 1364 query names they will match.  The owner name of the wildcard RRs is of     
 1365 the form "*.<anydomain>", where <anydomain> is any domain name.            
 1366 <anydomain> should not contain other * labels, and should be in the        
 1367 authoritative data of the zone.  The wildcards potentially apply to        
 1368 descendants of <anydomain>, but not to <anydomain> itself.  Another way    
 1372 Mockapetris                                                    [Page 25]   

 1373 RFC 1034             Domain Concepts and Facilities        November 1987   
 1376 to look at this is that the "*" label always matches at least one whole    
 1377 label and sometimes more, but always whole labels.                         
 1379 Wildcard RRs do not apply:                                                 
 1381    - When the query is in another zone.  That is, delegation cancels       
 1382      the wildcard defaults.                                                
line-1341 Robert Edmonds(Technical Erratum #4740) [Verified]
based on outdated version
   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.
It should say:
   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the queryresponse.  Exit.

Changed "query" to "response".

Section 4.3.2 describes the algorithm used by nameservers to answer queries. I.e., a nameserver receives a query from a client, and then it performs this algorithm in order to construct a response to send to the client.

Steps 1, 3, and 5 of this algorithm talk about setting fields or bits in the response, or about adding resource records to the answer section of the response, but then step 6 says to add resource records to the additional section of the *query*. This doesn't make any sense, because the server is constructing a response to a query that it's already received. "Response" must have been intended instead.

 1384    - When the query name or a name between the wildcard domain and         
 1385      the query name is know to exist.  For example, if a wildcard          
 1386      RR has an owner name of "*.X", and the zone also contains RRs         
 1387      attached to B.X, the wildcards would apply to queries for name        
 1388      Z.X (presuming there is no explicit information for Z.X), but         
 1389      not to B.X, A.B.X, or X.                                              
line-1384 Sun Congyou(Editorial Erratum #4230) [Held for Document Update]
based on outdated version
   - When the query name or a name between the wildcard domain and
     the query name is know to exist.
It should say:
   - When the query name or a name between the wildcard domain and
     the query name is known to exist.
 1391 A * label appearing in a query name has no special effect, but can be      
 1392 used to test for wildcards in an authoritative zone; such a query is the   
 1393 only way to get a response containing RRs with an owner name with * in     
 1394 it.  The result of such a query should not be cached.                      
 1396 Note that the contents of the wildcard RRs are not modified when used to   
 1397 synthesize RRs.                                                            
 1399 To illustrate the use of wildcard RRs, suppose a large company with a      
 1400 large, non-IP/TCP, network wanted to create a mail gateway.  If the        
 1401 company was called X.COM, and IP/TCP capable gateway machine was called    
 1402 A.X.COM, the following RRs might be entered into the COM zone:             
 1404     X.COM           MX      10      A.X.COM                                
 1406     *.X.COM         MX      10      A.X.COM                                
 1408     A.X.COM         A                                        
 1409     A.X.COM         MX      10      A.X.COM                                
 1411     *.A.X.COM       MX      10      A.X.COM                                
 1413 This would cause any MX query for any domain name ending in X.COM to       
 1414 return an MX RR pointing at A.X.COM.  Two wildcard RRs are required        
 1415 since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM    
 1416 subtree by the explicit data for A.X.COM.  Note also that the explicit     
 1417 MX data at X.COM and A.X.COM is required, and that none of the RRs above   
 1418 would match a query name of XX.COM.                                        
line-1391 Mukund Sivaraman(Technical Erratum #5316) [Held for Document Update]
based on outdated version
A * label appearing in a query name has no special effect, but can be
used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it.  The result of such a query should not be cached.
It should say:
A * label appearing in a query name has no special effect, but can be
used to test for wildcards in an authoritative zone; such a query is the
only way to get a response containing RRs with an owner name with * in
it.  The result of such a query should not be cachedused to synthesize RRs.

It is perfectly OK for an RR with a wildcard label '*' to be cached as long as it's not used to synthesize any RRs on a caching resolver. The DNS implementations BIND and Unbound both cache such RRsets with wildcard label in the owner name.

WK (OpsAD): Please see thread https://www.ietf.org/mail-archive/web/dnsop/current/msg22563.html for additional information.

 1420 4.3.4. Negative response caching (Optional)                                
 1422 The DNS provides an optional service which allows name servers to          
 1423 distribute, and resolvers to cache, negative results with TTLs.  For       
 1427 Mockapetris                                                    [Page 26]   

 1428 RFC 1034             Domain Concepts and Facilities        November 1987   
 1431 example, a name server can distribute a TTL along with a name error        
 1432 indication, and a resolver receiving such information is allowed to        
 1433 assume that the name does not exist during the TTL period without          
 1434 consulting authoritative data.  Similarly, a resolver can make a query     
 1435 with a QTYPE which matches multiple types, and cache the fact that some    
 1436 of the types are not present.                                              

Section 7.1 of RFC2181 says:

RFC1034, in section 3.7, indicates that the authority section of an
authoritative answer may contain the SOA record for the zone from
which the answer was obtained.  When discussing negative caching,
RFC1034 section 4.3.4 refers to this technique but mentions the
additional section of the response.  The former is correct, as is
implied by the example shown in section 6.2.5 of RFC1034.  SOA
records, if added, are to be placed in the authority section.

RFC2308 is a major restatement and update to how negative caching should be implemented. Its abstract begins:

[RFC1034] provided a description of how to cache negative responses.
It however had a fundamental flaw in that it did not allow a name
server to hand out those cached responses to other resolvers, thereby
greatly reducing the effect of the caching.  This document addresses
issues raise in the light of experience and replaces [RFC1034 Section

 1438 This feature can be particularly important in a system which implements    
 1439 naming shorthands that use search lists beacuse a popular shorthand,       
 1440 which happens to require a suffix toward the end of the search list,       
 1441 will generate multiple name errors whenever it is used.                    
 1443 The method is that a name server may add an SOA RR to the additional       
 1444 section of a response when that response is authoritative.  The SOA must   
 1445 be that of the zone which was the source of the authoritative data in      
 1446 the answer section, or name error if applicable.  The MINIMUM field of     
 1447 the SOA controls the length of time that the negative result may be        
 1448 cached.                                                                    
 1450 Note that in some circumstances, the answer section may contain multiple   
 1451 owner names.  In this case, the SOA mechanism should only be used for      
 1452 the data which matches QNAME, which is the only authoritative data in      
 1453 this section.                                                              
 1455 Name servers and resolvers should never attempt to add SOAs to the         
 1456 additional section of a non-authoritative response, or attempt to infer    
 1457 results which are not directly stated in an authoritative response.        
 1458 There are several reasons for this, including: cached information isn't    
 1459 usually enough to match up RRs and their zone names, SOA RRs may be        
 1460 cached due to direct SOA queries, and name servers are not required to     
 1461 output the SOAs in the authority section.                                  
 1463 This feature is optional, although a refined version is expected to        
 1464 become part of the standard protocol in the future.  Name servers are      
 1465 not required to add the SOA RRs in all authoritative responses, nor are    
 1466 resolvers required to cache negative results.  Both are recommended.       
 1467 All resolvers and recursive name servers are required to at least be       
 1468 able to ignore the SOA RR when it is present in a response.                
 1470 Some experiments have also been proposed which will use this feature.      
 1471 The idea is that if cached data is known to come from a particular zone,   
 1472 and if an authoritative copy of the zone's SOA is obtained, and if the     
 1473 zone's SERIAL has not changed since the data was cached, then the TTL of   
 1474 the cached data can be reset to the zone MINIMUM value if it is smaller.   
 1475 This usage is mentioned for planning purposes only, and is not             
 1476 recommended as yet.                                                        
 1482 Mockapetris                                                    [Page 27]   

 1483 RFC 1034             Domain Concepts and Facilities        November 1987   
 1486 4.3.5. Zone maintenance and transfers                                      
 1488 Part of the job of a zone administrator is to maintain the zones at all    
 1489 of the name servers which are authoritative for the zone.  When the        
 1490 inevitable changes are made, they must be distributed to all of the name   
 1491 servers.  While this distribution can be accomplished using FTP or some    
 1492 other ad hoc procedure, the preferred method is the zone transfer part     
 1493 of the DNS protocol.                                                       
 1495 The general model of automatic zone transfer or refreshing is that one     
 1496 of the name servers is the master or primary for the zone.  Changes are    
 1497 coordinated at the primary, typically by editing a master file for the     
 1498 zone.  After editing, the administrator signals the master server to       
 1499 load the new zone.  The other non-master or secondary servers for the      
 1500 zone periodically check for changes (at a selectable interval) and         
 1501 obtain new zone copies when changes have been made.                        
line-1438 John Kristoff(Editorial Erratum #1074) [Verified]
based on outdated version
Section 4.3.4 says:
  This feature can be particularly important in a system which implements
  naming short shorts that use search lists beacuse a popular shorthand,
  This feature can be particularly important in a system which implements
  naming short shorts that use search lists beacusebecause a popular shorthand,
 1503 To detect changes, secondaries just check the SERIAL field of the SOA      
 1504 for the zone.  In addition to whatever other changes are made, the         
 1505 SERIAL field in the SOA of the zone is always advanced whenever any        
 1506 change is made to the zone.  The advancing can be a simple increment, or   
 1507 could be based on the write date and time of the master file, etc.  The    
 1508 purpose is to make it possible to determine which of two copies of a       
 1509 zone is more recent by comparing serial numbers.  Serial number advances   
 1510 and comparisons use sequence space arithmetic, so there is a theoretic     
 1511 limit on how fast a zone can be updated, basically that old copies must    
 1512 die out before the serial number covers half of its 32 bit range.  In      
 1513 practice, the only concern is that the compare operation deals properly    
 1514 with comparisons around the boundary between the most positive and most    
 1515 negative 32 bit numbers.                                                   
 1517 The periodic polling of the secondary servers is controlled by             
 1518 parameters in the SOA RR for the zone, which set the minimum acceptable    
 1519 polling intervals.  The parameters are called REFRESH, RETRY, and          
 1520 EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary       
 1521 waits REFRESH seconds before checking with the primary for a new serial.   
 1522 If this check cannot be completed, new checks are started every RETRY      
 1523 seconds.  The check is a simple query to the primary for the SOA RR of     
 1524 the zone.  If the serial field in the secondary's zone copy is equal to    
 1525 the serial returned by the primary, then no changes have occurred, and     
 1526 the REFRESH interval wait is restarted.  If the secondary finds it         

RFC1982 clarifies how serial number arithmetic should be performed. The abstract says "The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood. This memo supplies the missing definition."

 1527 impossible to perform a serial check for the EXPIRE interval, it must      
 1528 assume that its copy of the zone is obsolete an discard it.                
line-1527 Shane Kerr(Editorial Erratum #4943) [Verified]
based on outdated version
it must assume that its copy of the zone is obsolete an discard it.
It should say:
it must assume that its copy of the zone is obsolete and discard it.

Fix typo; "an" should be "and".
 1530 When the poll shows that the zone has changed, then the secondary server   
 1531 must request a zone transfer via an AXFR request for the zone.  The AXFR   
 1532 may cause an error, such as refused, but normally is answered by a         
 1533 sequence of response messages.  The first and last messages must contain   
 1537 Mockapetris                                                    [Page 28]   

 1538 RFC 1034             Domain Concepts and Facilities        November 1987   
 1541 the data for the top authoritative node of the zone.  Intermediate         
 1542 messages carry all of the other RRs from the zone, including both          
 1543 authoritative and non-authoritative RRs.  The stream of messages allows    
 1544 the secondary to construct a copy of the zone.  Because accuracy is        
 1545 essential, TCP or some other reliable protocol must be used for AXFR       
 1546 requests.                                                                  
 1548 Each secondary server is required to perform the following operations      
 1549 against the master, but may also optionally perform these operations       
 1550 against other secondary servers.  This strategy can improve the transfer   
 1551 process when the primary is unavailable due to host downtime or network    
 1552 problems, or when a secondary server has better network access to an       
 1553 "intermediate" secondary than to the primary.                              
 1555 5. RESOLVERS                                                               
 1557 5.1. Introduction                                                          
 1559 Resolvers are programs that interface user programs to domain name         
 1560 servers.  In the simplest case, a resolver receives a request from a       
 1561 user program (e.g., mail programs, TELNET, FTP) in the form of a           
 1562 subroutine call, system call etc., and returns the desired information     
 1563 in a form compatible with the local host's data formats.                   
 1565 The resolver is located on the same machine as the program that requests   
 1566 the resolver's services, but it may need to consult name servers on        
 1567 other hosts.  Because a resolver may need to consult several name          
 1568 servers, or may have the requested information in a local cache, the       
 1569 amount of time that a resolver will take to complete can vary quite a      
 1570 bit, from milliseconds to several seconds.                                 
 1572 A very important goal of the resolver is to eliminate network delay and    
 1573 name server load from most requests by answering them from its cache of    
 1574 prior results.  It follows that caches which are shared by multiple        
 1575 processes, users, machines, etc., are more efficient than non-shared       
 1576 caches.                                                                    
 1578 5.2. Client-resolver interface                                             
 1580 5.2.1. Typical functions                                                   
 1582 The client interface to the resolver is influenced by the local host's     
 1583 conventions, but the typical resolver-client interface has three           
 1584 functions:                                                                 
 1586    1. Host name to host address translation.                               
 1588       This function is often defined to mimic a previous HOSTS.TXT         
 1592 Mockapetris                                                    [Page 29]   

 1593 RFC 1034             Domain Concepts and Facilities        November 1987   
 1596       based function.  Given a character string, the caller wants          
 1597       one or more 32 bit IP addresses.  Under the DNS, it                  
 1598       translates into a request for type A RRs.  Since the DNS does        
 1599       not preserve the order of RRs, this function may choose to           
 1600       sort the returned addresses or select the "best" address if          
 1601       the service returns only one choice to the client.  Note that        
 1602       a multiple address return is recommended, but a single               
 1603       address may be the only way to emulate prior HOSTS.TXT               
 1604       services.                                                            
 1606    2. Host address to host name translation                                
 1608       This function will often follow the form of previous                 
 1609       functions.  Given a 32 bit IP address, the caller wants a            
 1610       character string.  The octets of the IP address are reversed,        
 1611       used as name components, and suffixed with "IN-ADDR.ARPA".  A        
 1612       type PTR query is used to get the RR with the primary name of        
 1613       the host.  For example, a request for the host name                  
 1614       corresponding to IP address looks for PTR RRs for            
 1615       domain name "".                                  
 1617    3. General lookup function                                              
 1619       This function retrieves arbitrary information from the DNS,          
 1620       and has no counterpart in previous systems.  The caller              
 1621       supplies a QNAME, QTYPE, and QCLASS, and wants all of the            
 1622       matching RRs.  This function will often use the DNS format           
 1623       for all RR data instead of the local host's, and returns all         
 1624       RR content (e.g., TTL) instead of a processed form with local        
 1625       quoting conventions.                                                 
 1627 When the resolver performs the indicated function, it usually has one of   
 1628 the following results to pass back to the client:                          
 1630    - One or more RRs giving the requested data.                            
 1632      In this case the resolver returns the answer in the                   
 1633      appropriate format.                                                   
 1635    - A name error (NE).                                                    
 1637      This happens when the referenced name does not exist.  For            
 1638      example, a user may have mistyped a host name.                        
 1640    - A data not found error.                                               
 1642      This happens when the referenced name exists, but data of the         
 1643      appropriate type does not.  For example, a host address               
 1647 Mockapetris                                                    [Page 30]   

 1648 RFC 1034             Domain Concepts and Facilities        November 1987   
 1651      function applied to a mailbox name would return this error            
 1652      since the name exists, but no address RR is present.                  
 1654 It is important to note that the functions for translating between host    
 1655 names and addresses may combine the "name error" and "data not found"      
 1656 error conditions into a single type of error return, but the general       
 1657 function should not.  One reason for this is that applications may ask     
 1658 first for one type of information about a name followed by a second        
 1659 request to the same name for some other type of information; if the two    
 1660 errors are combined, then useless queries may slow the application.        
 1662 5.2.2. Aliases                                                             
 1664 While attempting to resolve a particular request, the resolver may find    
 1665 that the name in question is an alias.  For example, the resolver might    
 1666 find that the name given for host name to address translation is an        
 1667 alias when it finds the CNAME RR.  If possible, the alias condition        
 1668 should be signalled back from the resolver to the client.                  
 1670 In most cases a resolver simply restarts the query at the new name when    
 1671 it encounters a CNAME.  However, when performing the general function,     
 1672 the resolver should not pursue aliases when the CNAME RR matches the       
 1673 query type.  This allows queries which ask whether an alias is present.    
 1674 For example, if the query type is CNAME, the user is interested in the     
 1675 CNAME RR itself, and not the RRs at the name it points to.                 
 1677 Several special conditions can occur with aliases.  Multiple levels of     
 1678 aliases should be avoided due to their lack of efficiency, but should      
 1679 not be signalled as an error.  Alias loops and aliases which point to      
 1680 non-existent names should be caught and an error condition passed back     
 1681 to the client.                                                             
 1683 5.2.3. Temporary failures                                                  
 1685 In a less than perfect world, all resolvers will occasionally be unable    
 1686 to resolve a particular request.  This condition can be caused by a        
 1687 resolver which becomes separated from the rest of the network due to a     
 1688 link failure or gateway problem, or less often by coincident failure or    
 1689 unavailability of all servers for a particular domain.                     
 1691 It is essential that this sort of condition should not be signalled as a   
 1692 name or data not present error to applications.  This sort of behavior     
 1693 is annoying to humans, and can wreak havoc when mail systems use the       
 1694 DNS.                                                                       
 1696 While in some cases it is possible to deal with such a temporary problem   
 1697 by blocking the request indefinitely, this is usually not a good choice,   
 1698 particularly when the client is a server process that could move on to     
 1702 Mockapetris                                                    [Page 31]   

 1703 RFC 1034             Domain Concepts and Facilities        November 1987   
 1706 other tasks.  The recommended solution is to always have temporary         
 1707 failure as one of the possible results of a resolver function, even        
 1708 though this may make emulation of existing HOSTS.TXT functions more        
 1709 difficult.                                                                 
 1711 5.3. Resolver internals                                                    
 1713 Every resolver implementation uses slightly different algorithms, and      
 1714 typically spends much more logic dealing with errors of various sorts      

RFC5936 is a complete re-definition of AXFR. Its abstract says: "The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism."

 1715 than typical occurances.  This section outlines a recommended basic        
 1716 strategy for resolver operation, but leaves details to [RFC-1035].         
 1718 5.3.1. Stub resolvers                                                      
 1720 One option for implementing a resolver is to move the resolution           
 1721 function out of the local machine and into a name server which supports    
 1722 recursive queries.  This can provide an easy method of providing domain    
 1723 service in a PC which lacks the resources to perform the resolver          
 1724 function, or can centralize the cache for a whole local network or         
 1725 organization.                                                              
 1727 All that the remaining stub needs is a list of name server addresses       
 1728 that will perform the recursive requests.  This type of resolver           
 1729 presumably needs the information in a configuration file, since it         
 1730 probably lacks the sophistication to locate it in the domain database.     
 1731 The user also needs to verify that the listed servers will perform the     
 1732 recursive service; a name server is free to refuse to perform recursive    
 1733 services for any or all clients.  The user should consult the local        
 1734 system administrator to find name servers willing to perform the           
 1735 service.                                                                   
 1737 This type of service suffers from some drawbacks.  Since the recursive     
 1738 requests may take an arbitrary amount of time to perform, the stub may     
 1739 have difficulty optimizing retransmission intervals to deal with both      
 1740 lost UDP packets and dead servers; the name server can be easily           
 1741 overloaded by too zealous a stub if it interprets retransmissions as new   
 1742 requests.  Use of TCP may be an answer, but TCP may well place burdens     
 1743 on the host's capabilities which are similar to those of a real            
 1744 resolver.                                                                  
 1746 5.3.2. Resources                                                           
 1748 In addition to its own resources, the resolver may also have shared        
 1749 access to zones maintained by a local name server.  This gives the         
 1750 resolver the advantage of more rapid access, but the resolver must be      
 1751 careful to never let cached information override zone data.  In this       
 1752 discussion the term "local information" is meant to mean the union of      
 1753 the cache and such shared zones, with the understanding that               
 1757 Mockapetris                                                    [Page 32]   

 1758 RFC 1034             Domain Concepts and Facilities        November 1987   
 1761 authoritative data is always used in preference to cached data when both   
 1762 are present.                                                               
 1764 The following resolver algorithm assumes that all functions have been      
 1765 converted to a general lookup function, and uses the following data        
 1766 structures to represent the state of a request in progress in the          
 1767 resolver:                                                                  
 1769 SNAME           the domain name we are searching for.                      
 1771 STYPE           the QTYPE of the search request.                           
 1773 SCLASS          the QCLASS of the search request.                          
 1775 SLIST           a structure which describes the name servers and the       
 1776                 zone which the resolver is currently trying to query.      
 1777                 This structure keeps track of the resolver's current       
 1778                 best guess about which name servers hold the desired       
 1779                 information; it is updated when arriving information       
 1780                 changes the guess.  This structure includes the            
 1781                 equivalent of a zone name, the known name servers for      
 1782                 the zone, the known addresses for the name servers, and    
 1783                 history information which can be used to suggest which     
 1784                 server is likely to be the best one to try next.  The      
 1785                 zone name equivalent is a match count of the number of     
 1786                 labels from the root down which SNAME has in common with   
 1787                 the zone being queried; this is used as a measure of how   
 1788                 "close" the resolver is to SNAME.                          
 1790 SBELT           a "safety belt" structure of the same form as SLIST,       
 1791                 which is initialized from a configuration file, and        
 1792                 lists servers which should be used when the resolver       
 1793                 doesn't have any local information to guide name server    
 1794                 selection.  The match count will be -1 to indicate that    
 1795                 no labels are known to match.                              
 1797 CACHE           A structure which stores the results from previous         
 1798                 responses.  Since resolvers are responsible for            
 1799                 discarding old RRs whose TTL has expired, most             
 1800                 implementations convert the interval specified in          
 1801                 arriving RRs to some sort of absolute time when the RR     
 1802                 is stored in the cache.  Instead of counting the TTLs      
 1803                 down individually, the resolver just ignores or discards   
 1804                 old RRs when it runs across them in the course of a        
 1805                 search, or discards them during periodic sweeps to         
 1806                 reclaim the memory consumed by old RRs.                    
 1812 Mockapetris                                                    [Page 33]   

 1813 RFC 1034             Domain Concepts and Facilities        November 1987   
 1816 5.3.3. Algorithm                                                           
 1818 The top level algorithm has four steps:                                    
 1820    1. See if the answer is in local information, and if so return          
 1821       it to the client.                                                    
 1823    2. Find the best servers to ask.                                        
 1825    3. Send them queries until one returns a response.                      
 1827    4. Analyze the response, either:                                        
 1829          a. if the response answers the question or contains a name        
 1830             error, cache the data as well as returning it back to          
 1831             the client.                                                    
 1833          b. if the response contains a better delegation to other          
 1834             servers, cache the delegation information, and go to           
 1835             step 2.                                                        
 1837          c. if the response shows a CNAME and that is not the              
 1838             answer itself, cache the CNAME, change the SNAME to the        
 1839             canonical name in the CNAME RR and go to step 1.               
 1841          d. if the response shows a servers failure or other               
 1842             bizarre contents, delete the server from the SLIST and         
 1843             go back to step 3.                                             
 1845 Step 1 searches the cache for the desired data. If the data is in the      
 1846 cache, it is assumed to be good enough for normal use.  Some resolvers     
 1847 have an option at the user interface which will force the resolver to      
 1848 ignore the cached data and consult with an authoritative server.  This     
 1849 is not recommended as the default.  If the resolver has direct access to   
 1850 a name server's zones, it should check to see if the desired data is       
 1851 present in authoritative form, and if so, use the authoritative data in    
 1852 preference to cached data.                                                 
 1854 Step 2 looks for a name server to ask for the required data.  The          
 1855 general strategy is to look for locally-available name server RRs,         
 1856 starting at SNAME, then the parent domain name of SNAME, the               
 1857 grandparent, and so on toward the root.  Thus if SNAME were                
 1858 Mockapetris.ISI.EDU, this step would look for NS RRs for                   
 1859 Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).        
 1860 These NS RRs list the names of hosts for a zone at or above SNAME.  Copy   
 1861 the names into SLIST.  Set up their addresses using local data.  It may    
 1862 be the case that the addresses are not available.  The resolver has many   
 1863 choices here; the best is to start parallel resolver processes looking     
 1867 Mockapetris                                                    [Page 34]   

 1868 RFC 1034             Domain Concepts and Facilities        November 1987   
 1871 for the addresses while continuing onward with the addresses which are     
 1872 available.  Obviously, the design choices and options are complicated      
 1873 and a function of the local host's capabilities.  The recommended          
 1874 priorities for the resolver designer are:                                  
 1876    1. Bound the amount of work (packets sent, parallel processes           
 1877       started) so that a request can't get into an infinite loop or        
 1878       start off a chain reaction of requests or queries with other         
 1879       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED           
 1880       SOME DATA.                                                           
 1882    2. Get back an answer if at all possible.                               
 1884    3. Avoid unnecessary transmissions.                                     
 1886    4. Get the answer as quickly as possible.                               
 1888 If the search for NS RRs fails, then the resolver initializes SLIST from   
 1889 the safety belt SBELT.  The basic idea is that when the resolver has no    
 1890 idea what servers to ask, it should use information from a configuration   
 1891 file that lists several servers which are expected to be helpful.          
 1892 Although there are special situations, the usual choice is two of the      
 1893 root servers and two of the servers for the host's domain.  The reason     
 1894 for two of each is for redundancy.  The root servers will provide          
 1895 eventual access to all of the domain space.  The two local servers will    
 1896 allow the resolver to continue to resolve local names if the local         
 1897 network becomes isolated from the internet due to gateway or link          
 1898 failure.                                                                   
 1900 In addition to the names and addresses of the servers, the SLIST data      
 1901 structure can be sorted to use the best servers first, and to insure       
 1902 that all addresses of all servers are used in a round-robin manner.  The   
 1903 sorting can be a simple function of preferring addresses on the local      
 1904 network over others, or may involve statistics from past events, such as   
 1905 previous response times and batting averages.                              
 1907 Step 3 sends out queries until a response is received.  The strategy is    
 1908 to cycle around all of the addresses for all of the servers with a         
 1909 timeout between each transmission.  In practice it is important to use     
 1910 all addresses of a multihomed host, and too aggressive a retransmission    
 1911 policy actually slows response when used by multiple resolvers             
 1912 contending for the same name server and even occasionally for a single     
 1913 resolver.  SLIST typically contains data values to control the timeouts    
 1914 and keep track of previous transmissions.                                  
 1916 Step 4 involves analyzing responses.  The resolver should be highly        
 1917 paranoid in its parsing of responses.  It should also check that the       
 1918 response matches the query it sent using the ID field in the response.     
 1922 Mockapetris                                                    [Page 35]   

 1923 RFC 1034             Domain Concepts and Facilities        November 1987   
 1926 The ideal answer is one from a server authoritative for the query which    
 1927 either gives the required data or a name error.  The data is passed back   
 1928 to the user and entered in the cache for future use if its TTL is          
 1929 greater than zero.                                                         
 1931 If the response shows a delegation, the resolver should check to see       
 1932 that the delegation is "closer" to the answer than the servers in SLIST    
 1933 are.  This can be done by comparing the match count in SLIST with that     
 1934 computed from SNAME and the NS RRs in the delegation.  If not, the reply   
 1935 is bogus and should be ignored.  If the delegation is valid the NS         
 1936 delegation RRs and any address RRs for the servers should be cached.       
 1937 The name servers are entered in the SLIST, and the search is restarted.    
 1939 If the response contains a CNAME, the search is restarted at the CNAME     
 1940 unless the response has the data for the canonical name or if the CNAME    
 1941 is the answer itself.                                                      
 1943 Details and implementation hints can be found in [RFC-1035].               
 1945 6. A SCENARIO                                                              
 1947 In our sample domain space, suppose we wanted separate administrative      
 1948 control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might       
 1949 allocate name servers as follows:                                          
 1952                                    |(C.ISI.EDU,SRI-NIC.ARPA                
 1953                                    | A.ISI.EDU)                            
 1954              +---------------------+------------------+                    
 1955              |                     |                  |                    
 1956             MIL                   EDU                ARPA                  
 1957              |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |                    
 1958              | A.ISI.EDU           | C.ISI.EDU)       |                    
 1959        +-----+-----+               |     +------+-----+-----+              
 1960        |     |     |               |     |      |           |              
 1961       BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC             
 1962                                    |                                       
 1963        +--------+------------------+---------------+--------+              
 1964        |        |                  |               |        |              
 1965       UCI      MIT                 |              UDEL     YALE            
 1966                 |(XX.LCS.MIT.EDU, ISI                                      
 1967                 |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,          
 1968             +---+---+              | A.ISI.EDU)                            
 1969             |       |              |                                       
 1970            LCS   ACHILLES +--+-----+-----+--------+                        
 1971             |             |  |     |     |        |                        
 1972             XX            A  C   VAXA  VENERA Mockapetris                  
 1977 Mockapetris                                                    [Page 36]   

 1978 RFC 1034             Domain Concepts and Facilities        November 1987   
 1981 In this example, the authoritative name server is shown in parentheses     
 1982 at the point in the domain tree at which is assumes control.               
 1984 Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and             
 1985 A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The   
 1986 EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers    
 1987 may have zones which are contiguous or disjoint.  In this scenario,        
 1988 C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU     
 1989 has contiguous zones at the root and MIL domains, but also has a non-      
 1990 contiguous zone at ISI.EDU.                                                
 1992 6.1. C.ISI.EDU name server                                                 
 1994 C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN    
 1995 class, and would have zones for these domains.  The zone data for the      
 1996 root domain might be:                                                      
 1998     .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (       
 1999                             870611          ;serial                        
 2000                             1800            ;refresh every 30 min          
 2001                             300             ;retry every 5 min             
 2002                             604800          ;expire after a week           
 2003                             86400)          ;minimum of a day              
 2004                     NS      A.ISI.EDU.                                     
 2005                     NS      C.ISI.EDU.                                     
 2006                     NS      SRI-NIC.ARPA.                                  
 2008     MIL.    86400   NS      SRI-NIC.ARPA.                                  
 2009             86400   NS      A.ISI.EDU.                                     
 2011     EDU.    86400   NS      SRI-NIC.ARPA.                                  
 2012             86400   NS      C.ISI.EDU.                                     
 2014     SRI-NIC.ARPA.   A                                      
 2015                     A                                      
 2016                     MX      0 SRI-NIC.ARPA.                                
 2017                     HINFO   DEC-2060 TOPS20                                
 2019     ACC.ARPA.       A                                      
 2020                     HINFO   PDP-11/70 UNIX                                 
 2021                     MX      10 ACC.ARPA.                                   
 2023     USC-ISIC.ARPA.  CNAME   C.ISI.EDU.                                     
 2025  PTR    SRI-NIC.ARPA.                          
 2026  PTR    ACC.ARPA.                              
 2027  PTR    SRI-NIC.ARPA.                          
 2028  PTR    C.ISI.EDU.                             
 2032 Mockapetris                                                    [Page 37]   

 2033 RFC 1034             Domain Concepts and Facilities        November 1987   
 2036 PTR    A.ISI.EDU.                             
 2038     A.ISI.EDU. 86400 A                                     
 2039     C.ISI.EDU. 86400 A                                      
 2041 This data is represented as it would be in a master file.  Most RRs are    
 2042 single line entries; the sole exception here is the SOA RR, which uses     
 2043 "(" to start a multi-line RR and ")" to show the end of a multi-line RR.   
 2044 Since the class of all RRs in a zone must be the same, only the first RR   
 2045 in a zone need specify the class.  When a name server loads a zone, it     
 2046 forces the TTL of all authoritative RRs to be at least the MINIMUM field   
 2047 of the SOA, here 86400 seconds, or one day.  The NS RRs marking            
 2048 delegation of the MIL and EDU domains, together with the glue RRs for      
 2049 the servers host addresses, are not part of the authoritative data in      
 2050 the zone, and hence have explicit TTLs.                                    
 2052 Four RRs are attached to the root node: the SOA which describes the root   
 2053 zone and the 3 NS RRs which list the name servers for the root.  The       
 2054 data in the SOA RR describes the management of the zone.  The zone data    
 2055 is maintained on host SRI-NIC.ARPA, and the responsible party for the      
 2056 zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400       
 2057 second minimum TTL, which means that all authoritative data in the zone    
 2058 has at least that TTL, although higher values may be explicitly            
 2059 specified.                                                                 
 2061 The NS RRs for the MIL and EDU domains mark the boundary between the       
 2062 root zone and the MIL and EDU zones.  Note that in this example, the       
 2063 lower zones happen to be supported by name servers which also support      
 2064 the root zone.                                                             
 2066 The master file for the EDU zone might be stated relative to the origin    
 2067 EDU.  The zone data for the EDU domain might be:                           
 2069     EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (                  
 2070                             870729 ;serial                                 
 2071                             1800 ;refresh every 30 minutes                 
 2072                             300 ;retry every 5 minutes                     
 2073                             604800 ;expire after a week                    
 2074                             86400 ;minimum of a day                        
 2075                             )                                              
 2076                     NS SRI-NIC.ARPA.                                       
 2077                     NS C.ISI.EDU.                                          
 2079     UCI 172800 NS ICS.UCI                                                  
 2080                     172800 NS ROME.UCI                                     
 2081     ICS.UCI 172800 A                                            
 2082     ROME.UCI 172800 A                                          
 2087 Mockapetris                                                    [Page 38]   

 2088 RFC 1034             Domain Concepts and Facilities        November 1987   
 2091     ISI 172800 NS VAXA.ISI                                                 
 2092                     172800 NS A.ISI                                        
 2093                     172800 NS VENERA.ISI.EDU.                              
 2094     VAXA.ISI 172800 A                                            
 2095                     172800 A                                    
 2096     VENERA.ISI.EDU. 172800 A                                     
 2097                     172800 A                                    
 2098     A.ISI 172800 A                                              
 2100     UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.                                   
 2101                     172800 NS UMN-REI-UC.ARPA.                             
 2102     LOUIE.UDEL.EDU. 172800 A                                     
 2103                     172800 A                                    
 2105     YALE.EDU.  172800 NS YALE.ARPA.                                        
 2106     YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.                                
 2108     MIT.EDU.  43200 NS XX.LCS.MIT.EDU.                                     
 2109                       43200 NS ACHILLES.MIT.EDU.                           
 2110     XX.LCS.MIT.EDU.  43200 A                                     
 2111     ACHILLES.MIT.EDU. 43200 A                                    
 2113 Note the use of relative names here.  The owner name for the ISI.EDU. is   
 2114 stated using a relative name, as are two of the name server RR contents.   
line-1715 Ivan Panchenko(Editorial Erratum #6460) [Verified]
based on outdated version
than typical occurances.  This section outlines a recommended basic
It should say:
than typical occurarences.  This section outlines a recommended basic

Misspelled "occurrences".
 2115 Relative and absolute domain names may be freely intermixed in a master    
 2117 6.2. Example standard queries                                              
 2119 The following queries and responses illustrate name server behavior.       
 2120 Unless otherwise noted, the queries do not have recursion desired (RD)     
 2121 in the header.  Note that the answers to non-recursive queries do depend   
 2122 on the server being asked, but do not depend on the identity of the        
 2123 requester.                                                                 
 2142 Mockapetris                                                    [Page 39]   

 2143 RFC 1034             Domain Concepts and Facilities        November 1987   
 2146 6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A                                         
 2148 The query would look like:                                                 
 2150                +---------------------------------------------------+       
 2151     Header     | OPCODE=SQUERY                                     |       
 2152                +---------------------------------------------------+       
 2153     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |       
 2154                +---------------------------------------------------+       
 2155     Answer     | <empty>                                           |       
 2156                +---------------------------------------------------+       
 2157     Authority  | <empty>                                           |       
 2158                +---------------------------------------------------+       
 2159     Additional | <empty>                                           |       
 2160                +---------------------------------------------------+       
 2162 The response from C.ISI.EDU would be:                                      
 2164                +---------------------------------------------------+       
 2165     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2166                +---------------------------------------------------+       
 2167     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |       
 2168                +---------------------------------------------------+       
 2169     Answer     | SRI-NIC.ARPA. 86400 IN A                |       
 2170                |               86400 IN A                |       
 2171                +---------------------------------------------------+       
 2172     Authority  | <empty>                                           |       
 2173                +---------------------------------------------------+       
 2174     Additional | <empty>                                           |       
 2175                +---------------------------------------------------+       
 2177 The header of the response looks like the header of the query, except      
 2178 that the RESPONSE bit is set, indicating that this message is a            
 2179 response, not a query, and the Authoritative Answer (AA) bit is set        
 2180 indicating that the address RRs in the answer section are from             
 2181 authoritative data.  The question section of the response matches the      
 2182 question section of the query.                                             
 2197 Mockapetris                                                    [Page 40]   

 2198 RFC 1034             Domain Concepts and Facilities        November 1987   
 2201 If the same query was sent to some other server which was not              
 2202 authoritative for SRI-NIC.ARPA, the response might be:                     
 2204                +---------------------------------------------------+       
 2205     Header     | OPCODE=SQUERY,RESPONSE                            |       
 2206                +---------------------------------------------------+       
 2207     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |       
 2208                +---------------------------------------------------+       
 2209     Answer     | SRI-NIC.ARPA. 1777 IN A                 |       
 2210                |               1777 IN A                 |       
 2211                +---------------------------------------------------+       
 2212     Authority  | <empty>                                           |       
 2213                +---------------------------------------------------+       
 2214     Additional | <empty>                                           |       
 2215                +---------------------------------------------------+       
 2217 This response is different from the previous one in two ways: the header   
 2218 does not have AA set, and the TTLs are different.  The inference is that   
 2219 the data did not come from a zone, but from a cache.  The difference       
 2220 between the authoritative TTL and the TTL here is due to aging of the      
 2221 data in a cache.  The difference in ordering of the RRs in the answer      
 2222 section is not significant.                                                
 2224 6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*                                         
 2226 A query similar to the previous one, but using a QTYPE of *, would         
 2227 receive the following response from C.ISI.EDU:                             
 2229                +---------------------------------------------------+       
 2230     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2231                +---------------------------------------------------+       
 2232     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |       
 2233                +---------------------------------------------------+       
 2234     Answer     | SRI-NIC.ARPA. 86400 IN  A           |       
 2235                |                         A           |       
 2236                |                         MX    0 SRI-NIC.ARPA.     |       
 2237                |                         HINFO DEC-2060 TOPS20     |       
 2238                +---------------------------------------------------+       
 2239     Authority  | <empty>                                           |       
 2240                +---------------------------------------------------+       
 2241     Additional | <empty>                                           |       
 2242                +---------------------------------------------------+       
 2252 Mockapetris                                                    [Page 41]   

 2253 RFC 1034             Domain Concepts and Facilities        November 1987   
 2256 If a similar query was directed to two name servers which are not          
 2257 authoritative for SRI-NIC.ARPA, the responses might be:                    
 2259                +---------------------------------------------------+       
 2260     Header     | OPCODE=SQUERY, RESPONSE                           |       
 2261                +---------------------------------------------------+       
 2262     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |       
 2263                +---------------------------------------------------+       
 2264     Answer     | SRI-NIC.ARPA. 12345 IN     A      |       
 2265                |                            A      |       
 2266                +---------------------------------------------------+       
 2267     Authority  | <empty>                                           |       
 2268                +---------------------------------------------------+       
 2269     Additional | <empty>                                           |       
 2270                +---------------------------------------------------+       
 2272 and                                                                        
 2274                +---------------------------------------------------+       
 2275     Header     | OPCODE=SQUERY, RESPONSE                           |       
 2276                +---------------------------------------------------+       
 2277     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |       
 2278                +---------------------------------------------------+       
 2279     Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |       
 2280                +---------------------------------------------------+       
 2281     Authority  | <empty>                                           |       
 2282                +---------------------------------------------------+       
 2283     Additional | <empty>                                           |       
 2284                +---------------------------------------------------+       
 2286 Neither of these answers have AA set, so neither response comes from       
 2287 authoritative data.  The different contents and different TTLs suggest     
 2288 that the two servers cached data at different times, and that the first    
 2289 server cached the response to a QTYPE=A query and the second cached the    
 2290 response to a HINFO query.                                                 
 2307 Mockapetris                                                    [Page 42]   

 2308 RFC 1034             Domain Concepts and Facilities        November 1987   
 2311 6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX                                        
 2313 This type of query might be result from a mailer trying to look up         
 2314 routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.      
 2315 The response from C.ISI.EDU would be:                                      
 2317                +---------------------------------------------------+       
 2318     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2319                +---------------------------------------------------+       
 2320     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |       
 2321                +---------------------------------------------------+       
 2322     Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|       
 2323                +---------------------------------------------------+       
 2324     Authority  | <empty>                                           |       
 2325                +---------------------------------------------------+       
 2326     Additional | SRI-NIC.ARPA. 86400 IN     A      |       
 2327                |                            A      |       
 2328                +---------------------------------------------------+       
 2330 This response contains the MX RR in the answer section of the response.    
 2331 The additional section contains the address RRs because the name server    
 2332 at C.ISI.EDU guesses that the requester will need the addresses in order   
 2333 to properly use the information carried by the MX.                         
 2335 6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS                                        
 2337 C.ISI.EDU would reply to this query with:                                  
 2339                +---------------------------------------------------+       
 2340     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2341                +---------------------------------------------------+       
 2342     Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |       
 2343                +---------------------------------------------------+       
 2344     Answer     | <empty>                                           |       
 2345                +---------------------------------------------------+       
 2346     Authority  | <empty>                                           |       
 2347                +---------------------------------------------------+       
 2348     Additional | <empty>                                           |       
 2349                +---------------------------------------------------+       
 2351 The only difference between the response and the query is the AA and       
 2352 RESPONSE bits in the header.  The interpretation of this response is       
 2353 that the server is authoritative for the name, and the name exists, but    
 2354 no RRs of type NS are present there.                                       
 2356 6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A                                         
 2358 If a user mistyped a host name, we might see this type of query.           
 2362 Mockapetris                                                    [Page 43]   

 2363 RFC 1034             Domain Concepts and Facilities        November 1987   
 2366 C.ISI.EDU would answer it with:                                            
 2368                +---------------------------------------------------+       
 2369     Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |       
 2370                +---------------------------------------------------+       
 2371     Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |       
 2372                +---------------------------------------------------+       
 2373     Answer     | <empty>                                           |       
 2374                +---------------------------------------------------+       
 2375     Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |       
 2376                |       870611 1800 300 604800 86400                |       
 2377                +---------------------------------------------------+       
 2378     Additional | <empty>                                           |       
 2379                +---------------------------------------------------+       
 2381 This response states that the name does not exist.  This condition is      
 2382 signalled in the response code (RCODE) section of the header.              
 2384 The SOA RR in the authority section is the optional negative caching       
 2385 information which allows the resolver using this response to assume that   
 2386 the name will not exist for the SOA MINIMUM (86400) seconds.               
 2388 6.2.6. QNAME=BRL.MIL, QTYPE=A                                              
 2390 If this query is sent to C.ISI.EDU, the reply would be:                    
 2392                +---------------------------------------------------+       
 2393     Header     | OPCODE=SQUERY, RESPONSE                           |       
 2394                +---------------------------------------------------+       
 2395     Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |       
 2396                +---------------------------------------------------+       
 2397     Answer     | <empty>                                           |       
 2398                +---------------------------------------------------+       
 2399     Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |       
 2400                |                  86400    NS       A.ISI.EDU.     |       
 2401                +---------------------------------------------------+       
 2402     Additional | A.ISI.EDU.                A     |       
 2403                | SRI-NIC.ARPA.             A      |       
 2404                |                           A      |       
 2405                +---------------------------------------------------+       
 2407 This response has an empty answer section, but is not authoritative, so    
 2408 it is a referral.  The name server on C.ISI.EDU, realizing that it is      
 2409 not authoritative for the MIL domain, has referred the requester to        
 2410 servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative    
 2411 for the MIL domain.                                                        
 2417 Mockapetris                                                    [Page 44]   

 2418 RFC 1034             Domain Concepts and Facilities        November 1987   
 2421 6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A                                        
 2423 The response to this query from A.ISI.EDU would be:                        
 2425                +---------------------------------------------------+       
 2426     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2427                +---------------------------------------------------+       
 2428     Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |       
 2429                +---------------------------------------------------+       
 2430     Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |       
 2431                | C.ISI.EDU.     86400 IN A      |       
 2432                +---------------------------------------------------+       
 2433     Authority  | <empty>                                           |       
 2434                +---------------------------------------------------+       
 2435     Additional | <empty>                                           |       
 2436                +---------------------------------------------------+       
 2438 Note that the AA bit in the header guarantees that the data matching       
 2439 QNAME is authoritative, but does not say anything about whether the data   
 2440 for C.ISI.EDU is authoritative.  This complete reply is possible because   
 2441 A.ISI.EDU happens to be authoritative for both the ARPA domain where       
 2442 USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is      
 2443 found.                                                                     
 2445 If the same query was sent to C.ISI.EDU, its response might be the same    
 2446 as shown above if it had its own address in its cache, but might also      
 2447 be:                                                                        
 2472 Mockapetris                                                    [Page 45]   

 2473 RFC 1034             Domain Concepts and Facilities        November 1987   
 2476                +---------------------------------------------------+       
 2477     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2478                +---------------------------------------------------+       
 2479     Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |       
 2480                +---------------------------------------------------+       
 2481     Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |       
 2482                +---------------------------------------------------+       
 2483     Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |       
 2484                |                           NS      A.ISI.EDU.      |       
 2485                |                           NS      VENERA.ISI.EDU. |       
 2486                +---------------------------------------------------+       
 2487     Additional | VAXA.ISI.EDU.   172800    A       |       
 2488                |                 172800    A      |       
 2489                | VENERA.ISI.EDU. 172800    A       |       
 2490                |                 172800    A      |       
 2491                | A.ISI.EDU.      172800    A      |       
 2492                +---------------------------------------------------+       
 2494 This reply contains an authoritative reply for the alias USC-ISIC.ARPA,    
 2495 plus a referral to the name servers for ISI.EDU.  This sort of reply       
 2496 isn't very likely given that the query is for the host name of the name    
 2497 server being asked, but would be common for other aliases.                 
 2499 6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME                                    
 2501 If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would    
 2502 be:                                                                        
 2504                +---------------------------------------------------+       
 2505     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2506                +---------------------------------------------------+       
line-2115 John Kristoff(Technical Erratum #755) [Held for Document Update]
based on outdated version
Section 6.1. ends this way:

  Relative and absolute domain names may be freely intermixed in a

which is incomplete.  It's unclear exactly how that sentence may have
been intended to end, but minimally I would suggeste it at least
terminated with 'file.'.
 2507     Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |       
 2508                +---------------------------------------------------+       
 2509     Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |       
 2510                +---------------------------------------------------+       
 2511     Authority  | <empty>                                           |       
 2512                +---------------------------------------------------+       
 2513     Additional | <empty>                                           |       
 2514                +---------------------------------------------------+       
 2516 Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name   
 2517 server doesn't attempt to look up anything for C.ISI.EDU.  (Except         
 2518 possibly for the additional section.)                                      
 2520 6.3. Example resolution                                                    
 2522 The following examples illustrate the operations a resolver must perform   
 2523 for its client.  We assume that the resolver is starting without a         
 2527 Mockapetris                                                    [Page 46]   

 2528 RFC 1034             Domain Concepts and Facilities        November 1987   
 2531 cache, as might be the case after system boot.  We further assume that     
 2532 the system is not one of the hosts in the data and that the host is        
 2533 located somewhere on net 26, and that its safety belt (SBELT) data         
 2534 structure has the following information:                                   
 2536     Match count = -1                                                       
 2537     SRI-NIC.ARPA.                              
 2538     A.ISI.EDU.                                             
 2540 This information specifies servers to try, their addresses, and a match    
 2541 count of -1, which says that the servers aren't very close to the          
 2542 target.  Note that the -1 isn't supposed to be an accurate closeness       
 2543 measure, just a value so that later stages of the algorithm will work.     
 2545 The following examples illustrate the use of a cache, so each example      
 2546 assumes that previous requests have completed.                             
 2548 6.3.1. Resolve MX for ISI.EDU.                                             
 2550 Suppose the first request to the resolver comes from the local mailer,     
 2551 which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX     
 2552 RRs for the domain name ISI.EDU.                                           
 2554 The resolver would look in its cache for MX RRs at ISI.EDU, but the        
 2555 empty cache wouldn't be helpful.  The resolver would recognize that it     
 2556 needed to query foreign servers and try to determine the best servers to   
 2557 query.  This search would look for NS RRs for the domains ISI.EDU, EDU,    
 2558 and the root.  These searches of the cache would also fail.  As a last     
 2559 resort, the resolver would use the information from the SBELT, copying     
 2560 it into its SLIST structure.                                               
 2562 At this point the resolver would need to pick one of the three available   
 2563 addresses to try.  Given that the resolver is on net 26, it should         
 2564 choose either or as its first choice.  It would       
 2565 then send off a query of the form:                                         
 2582 Mockapetris                                                    [Page 47]   

 2583 RFC 1034             Domain Concepts and Facilities        November 1987   
 2586                +---------------------------------------------------+       
 2587     Header     | OPCODE=SQUERY                                     |       
 2588                +---------------------------------------------------+       
 2589     Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |       
 2590                +---------------------------------------------------+       
 2591     Answer     | <empty>                                           |       
 2592                +---------------------------------------------------+       
 2593     Authority  | <empty>                                           |       
 2594                +---------------------------------------------------+       
 2595     Additional | <empty>                                           |       
 2596                +---------------------------------------------------+       
 2598 The resolver would then wait for a response to its query or a timeout.     
 2599 If the timeout occurs, it would try different servers, then different      
 2600 addresses of the same servers, lastly retrying addresses already tried.    
 2601 It might eventually receive a reply from SRI-NIC.ARPA:                     
 2603                +---------------------------------------------------+       
 2604     Header     | OPCODE=SQUERY, RESPONSE                           |       
 2605                +---------------------------------------------------+       
 2606     Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |       
 2607                +---------------------------------------------------+       
 2608     Answer     | <empty>                                           |       
 2609                +---------------------------------------------------+       
 2610     Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |       
 2611                |                           NS       A.ISI.EDU.     |       
 2612                |                           NS       VENERA.ISI.EDU.|       
 2613                +---------------------------------------------------+       
 2614     Additional | VAXA.ISI.EDU.   172800    A      |       
 2615                |                 172800    A     |       
 2616                | VENERA.ISI.EDU. 172800    A      |       
 2617                |                 172800    A     |       
 2618                | A.ISI.EDU.      172800    A     |       
 2619                +---------------------------------------------------+       
 2621 The resolver would notice that the information in the response gave a      
 2622 closer delegation to ISI.EDU than its existing SLIST (since it matches     
 2623 three labels).  The resolver would then cache the information in this      
 2624 response and use it to set up a new SLIST:                                 
 2626     Match count = 3                                                        
 2627     A.ISI.EDU.                                             
 2628     VAXA.ISI.EDU.                             
 2629     VENERA.ISI.EDU.                             
 2631 A.ISI.EDU appears on this list as well as the previous one, but that is    
 2632 purely coincidental.  The resolver would again start transmitting and      
 2633 waiting for responses.  Eventually it would get an answer:                 
 2637 Mockapetris                                                    [Page 48]   

 2638 RFC 1034             Domain Concepts and Facilities        November 1987   
 2641                +---------------------------------------------------+       
 2642     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2643                +---------------------------------------------------+       
 2644     Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |       
 2645                +---------------------------------------------------+       
 2646     Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |       
 2647                |                         MX 20 VAXA.ISI.EDU.       |       
 2648                +---------------------------------------------------+       
 2649     Authority  | <empty>                                           |       
 2650                +---------------------------------------------------+       
 2651     Additional | VAXA.ISI.EDU.   172800  A              |       
 2652                |                 172800  A             |       
 2653                | VENERA.ISI.EDU. 172800  A              |       
 2654                |                 172800  A             |       
 2655                +---------------------------------------------------+       
 2657 The resolver would add this information to its cache, and return the MX    
 2658 RRs to its client.                                                         
 2660 6.3.2. Get the host name for address                             
 2662 The resolver would translate this into a request for PTR RRs for           
 2663  This information is not in the cache, so the      
 2664 resolver would look for foreign servers to ask.  No servers would match,   
 2665 so it would use SBELT again.  (Note that the servers for the ISI.EDU       
 2666 domain are in the cache, but ISI.EDU is not an ancestor of                 
 2667, so the SBELT is used.)                             
 2669 Since this request is within the authoritative data of both servers in     
 2670 SBELT, eventually one would return:                                        
 2692 Mockapetris                                                    [Page 49]   

 2693 RFC 1034             Domain Concepts and Facilities        November 1987   
 2696                +---------------------------------------------------+       
 2697     Header     | OPCODE=SQUERY, RESPONSE, AA                       |       
 2698                +---------------------------------------------------+       
 2699     Question   | QNAME=,QCLASS=IN,QTYPE=PTR |       
 2700                +---------------------------------------------------+       
 2701     Answer     |    PTR     ACC.ARPA.      |       
 2702                +---------------------------------------------------+       
 2703     Authority  | <empty>                                           |       
 2704                +---------------------------------------------------+       
 2705     Additional | <empty>                                           |       
 2706                +---------------------------------------------------+       
 2708 6.3.3. Get the host address of poneria.ISI.EDU                             
 2710 This request would translate into a type A request for poneria.ISI.EDU.    
 2711 The resolver would not find any cached data for this name, but would       
 2712 find the NS RRs in the cache for ISI.EDU when it looks for foreign         
 2713 servers to ask.  Using this data, it would construct a SLIST of the        
 2714 form:                                                                      
 2716     Match count = 3                                                        
 2718     A.ISI.EDU.                                             
 2719     VAXA.ISI.EDU.                             
 2720     VENERA.ISI.EDU.                                              
 2722 A.ISI.EDU is listed first on the assumption that the resolver orders its   
 2723 choices by preference, and A.ISI.EDU is on the same network.               
 2725 One of these servers would answer the query.                               
 2727 7. REFERENCES and BIBLIOGRAPHY                                             
 2729 [Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena             
 2730                 Technical Plan - Name Service, April 1987, version 1.9.    
 2732                 Describes the fundamentals of the Hesiod name service.     
 2734 [IEN-116]       J. Postel, "Internet Name Server", IEN-116,                
 2735                 USC/Information Sciences Institute, August 1979.           
 2737                 A name service obsoleted by the Domain Name System, but    
 2738                 still in use.                                              
 2747 Mockapetris                                                    [Page 50]   

 2748 RFC 1034             Domain Concepts and Facilities        November 1987   
line-2507 John Kristoff(Technical Erratum #755) [Held for Document Update]
based on outdated version
Section 6.2.8. in the diagram shows 'QTYPE=A', but should be of
type 'CNAME' based on the context of the example.
It should say:
[see above]
 2751 [Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer          
 2752                 Networks",Communications of the ACM, October 1986,         
 2753                 volume 29, number 10.                                      
 2755 [RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network            
 2756                 Information Center, SRI International, December 1977.      
 2758 [RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,              
 2759                 USC/Information Sciences Institute, August 1980.           
 2761 [RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,       
 2762                 USC/Information Sciences Institute, September 1981.        
 2764 [RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,        
 2765                 September 1981.                                            
 2767                 Suggests introduction of a hierarchy in place of a flat    
 2768                 name space for the Internet.                               
 2770 [RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,         
 2771                 USC/Information Sciences Institute, February 1982.         
 2773 [RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD      
 2774                 Internet Host Table Specification", RFC-810, Network       
 2775                 Information Center, SRI International, March 1982.         
 2777                 Obsolete.  See RFC-952.                                    
 2779 [RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames       
 2780                 Server", RFC-811, Network Information Center, SRI          
 2781                 International, March 1982.                                 
 2783                 Obsolete.  See RFC-953.                                    
 2785 [RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,    
 2786                 Network Information Center, SRI International, March       
 2787                 1982.                                                      
 2789 [RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for    
 2790                 Internet User Applications", RFC-819, Network              
 2791                 Information Center, SRI International, August 1982.        
 2793                 Early thoughts on the design of the domain system.         
 2794                 Current implementation is completely different.            
 2796 [RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,       
 2797                 USC/Information Sciences Institute, August 1980.           
 2802 Mockapetris                                                    [Page 51]   

 2803 RFC 1034             Domain Concepts and Facilities        November 1987   
 2806 [RFC-830]       Z. Su, "A Distributed System for Internet Name Service",   
 2807                 RFC-830, Network Information Center, SRI International,    
 2808                 October 1982.                                              
 2810                 Early thoughts on the design of the domain system.         
 2811                 Current implementation is completely different.            
line-2751 Ivan Panchenko(Editorial Erratum #6461) [Verified]
based on outdated version
                Networks",Communications of the ACM, October 1986,
It should say:
                Networks", Communications of the ACM, October 1986,

Missing space.
 2813 [RFC-882]       P. Mockapetris, "Domain names - Concepts and               
 2814                 Facilities," RFC-882, USC/Information Sciences             
 2815                 Institute, November 1983.                                  
 2817                 Superceeded by this memo.                                  
 2819 [RFC-883]       P. Mockapetris, "Domain names - Implementation and         
 2820                 Specification," RFC-883, USC/Information Sciences          
 2821                 Institute, November 1983.                                  
 2823                 Superceeded by this memo.                                  
 2825 [RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",          
 2826                 RFC-920, USC/Information Sciences Institute                
 2827                 October 1984.                                              
 2829                 Explains the naming scheme for top level domains.          
 2831 [RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host   
 2832                 Table Specification", RFC-952, SRI, October 1985.          
 2834                 Specifies the format of HOSTS.TXT, the host/address        
 2835                 table replaced by the DNS.                                 
 2837 [RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",   
 2838                 RFC-953, SRI, October 1985.                                
 2840                 This RFC contains the official specification of the        
 2841                 hostname server protocol, which is obsoleted by the DNS.   
 2842                 This TCP based protocol accesses information stored in     
 2843                 the RFC-952 format, and is used to obtain copies of the    
 2844                 host table.                                                
 2846 [RFC-973]       P. Mockapetris, "Domain System Changes and                 
 2847                 Observations", RFC-973, USC/Information Sciences           
 2848                 Institute, January 1986.                                   
 2850                 Describes changes to RFC-882 and RFC-883 and reasons for   
 2851                 them.  Now obsolete.                                       
 2857 Mockapetris                                                    [Page 52]   

 2858 RFC 1034             Domain Concepts and Facilities        November 1987   
 2861 [RFC-974]       C. Partridge, "Mail routing and the domain system",        
 2862                 RFC-974, CSNET CIC BBN Labs, January 1986.                 
 2864                 Describes the transition from HOSTS.TXT based mail         
 2865                 addressing to the more powerful MX system used with the    
 2866                 domain system.                                             
 2868 [RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS    
 2869                 service on a TCP/UDP transport: Concepts and Methods",     
 2870                 RFC-1001, March 1987.                                      
 2872                 This RFC and RFC-1002 are a preliminary design for         
 2873                 NETBIOS on top of TCP/IP which proposes to base NetBIOS    
 2874                 name service on top of the DNS.                            
 2876 [RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS    
 2877                 service on a TCP/UDP transport: Detailed                   
 2878                 Specifications", RFC-1002, March 1987.                     
 2880 [RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,   
 2881                 USC/Information Sciences Institute, May 1987               
 2883                 Contains socket numbers and mnemonics for host names,      
 2884                 operating systems, etc.                                    
 2886 [RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,      
 2887                 November 1987.                                             
 2889                 Describes a plan for converting the MILNET to the DNS.     
 2891 [RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for       
 2892                 Administrators", RFC-1032, November 1987.                  
 2894                 Describes the registration policies used by the NIC to     
 2895                 administer the top level domains and delegate subzones.    
 2897 [RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",    
 2898                 RFC-1033, November 1987.                                   
 2900                 A cookbook for domain administrators.                      
 2902 [Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET     
 2903                 Name Server", Computer Networks, vol 6, nr 3, July 1982.   
 2905                 Describes a name service for CSNET which is independent    
 2906                 from the DNS and DNS use in the CSNET.                     
 2912 Mockapetris                                                    [Page 53]   

 2913 RFC 1034             Domain Concepts and Facilities        November 1987   
 2916 Index                                                                      
 2918           A   12                                                           
 2919           Absolute names   8                                               
 2920           Aliases   14, 31                                                 
 2921           Authority   6                                                    
 2922           AXFR   17                                                        
 2924           Case of characters   7                                           
 2925           CH   12                                                          
 2926           CNAME   12, 13, 31                                               
 2927           Completion queries   18                                          
 2929           Domain name   6, 7                                               
 2931           Glue RRs   20                                                    
 2933           HINFO   12                                                       
 2935           IN   12                                                          
 2936           Inverse queries   16                                             
 2937           Iterative   4                                                    
 2939           Label   7                                                        
 2941           Mailbox names   9                                                
 2942           MX   12                                                          
 2944           Name error   27, 36                                              
 2945           Name servers   5, 17                                             
 2946           NE   30                                                          
 2947           Negative caching   44                                            
 2948           NS   12                                                          
 2950           Opcode   16                                                      
 2952           PTR   12                                                         
 2954           QCLASS   16                                                      
 2955           QTYPE   16                                                       
 2957           RDATA   13                                                       
 2958           Recursive   4                                                    
 2959           Recursive service   22                                           
 2960           Relative names   7                                               
 2961           Resolvers   6                                                    
 2962           RR   12                                                          
 2967 Mockapetris                                                    [Page 54]   

 2968 RFC 1034             Domain Concepts and Facilities        November 1987   
 2971           Safety belt   33                                                 
 2972           Sections   16                                                    
 2973           SOA   12                                                         
 2974           Standard queries   22                                            
 2976           Status queries   18                                              
 2977           Stub resolvers   32                                              
 2979           TTL   12, 13                                                     
 2981           Wildcards   25                                                   
 2983           Zone transfers   28                                              
 2984           Zones   19                                                       
 3022 Mockapetris                                                    [Page 55]   
line-2813 Ivan Panchenko(Editorial Erratum #6462) [Verified]
based on outdated version
                Superceeded by this memo.
It should say:
                Superceeseded by this memo.

Misspelled "superseded".