1 Network Working Group                                             R. Elz   
    2 Request for Comments: 2181                       University of Melbourne   
    3 Updates: 1034, 1035, 1123                                        R. Bush   
    4 Category: Standards Track                                    RGnet, Inc.   
    5                                                                July 1997   
    8                 Clarifications to the DNS Specification                    
   10 Status of this Memo                                                        
   12    This document specifies an Internet standards track protocol for the    
   13    Internet community, and requests discussion and suggestions for         
   14    improvements.  Please refer to the current edition of the "Internet     
   15    Official Protocol Standards" (STD 1) for the standardization state      
   16    and status of this protocol.  Distribution of this memo is unlimited.   
   18 1. Abstract                                                                
   20    This document considers some areas that have been identified as         
   21    problems with the specification of the Domain Name System, and          
   22    proposes remedies for the defects identified.  Eight separate issues    
   23    are considered:                                                         
   25      + IP packet header address usage from multi-homed servers,            
   26      + TTLs in sets of records with the same name, class, and type,        
   27      + correct handling of zone cuts,                                      
   28      + three minor issues concerning SOA records and their use,            
   29      + the precise definition of the Time to Live (TTL)                    
   30      + Use of the TC (truncated) header bit                                
   31      + the issue of what is an authoritative, or canonical, name,          
   32      + and the issue of what makes a valid DNS label.                      
   34    The first six of these are areas where the correct behaviour has been   
   35    somewhat unclear, we seek to rectify that.  The other two are already   
   36    adequately specified, however the specifications seem to be sometimes   
   37    ignored.  We seek to reinforce the existing specifications.             
   52 Elz & Bush                  Standards Track                     [Page 1]   

   53 RFC 2181        Clarifications to the DNS Specification        July 1997   
   58 Contents                                                                   
   60     1  Abstract  ...................................................   1   
   61     2  Introduction  ...............................................   2   
   62     3  Terminology  ................................................   3   
   63     4  Server Reply Source Address Selection  ......................   3   
   64     5  Resource Record Sets  .......................................   4   
   65     6  Zone Cuts  ..................................................   8   
   66     7  SOA RRs  ....................................................  10   
   67     8  Time to Live (TTL)  .........................................  10   
   68     9  The TC (truncated) header bit  ..............................  11   
   69    10  Naming issues  ..............................................  11   
   70    11  Name syntax  ................................................  13   
   71    12  Security Considerations  ....................................  14   
   72    13  References  .................................................  14   
   73    14  Acknowledgements  ...........................................  15   
   74    15  Authors' Addresses  .........................................  15   
   79 2. Introduction                                                            
   81    Several problem areas in the Domain Name System specification           
   82    [RFC1034, RFC1035] have been noted through the years [RFC1123].  This   
   83    document addresses several additional problem areas.  The issues here   
   84    are independent.  Those issues are the question of which source         
   85    address a multi-homed DNS server should use when replying to a query,   
   86    the issue of differing TTLs for DNS records with the same label,        
   87    class and type, and the issue of canonical names, what they are, how    
   88    CNAME records relate, what names are legal in what parts of the DNS,    
   89    and what is the valid syntax of a DNS name.                             
   91    Clarifications to the DNS specification to avoid these problems are     
   92    made in this memo.  A minor ambiguity in RFC1034 concerned with SOA     
   93    records is also corrected, as is one in the definition of the TTL       
   94    (Time To Live) and some possible confusion in use of the TC bit.        
  107 Elz & Bush                  Standards Track                     [Page 2]   

  108 RFC 2181        Clarifications to the DNS Specification        July 1997   
  111 3. Terminology                                                             
  113    This memo does not use the oft used expressions MUST, SHOULD, MAY, or   
  114    their negative forms.  In some sections it may seem that a              
  115    specification is worded mildly, and hence some may infer that the       
  116    specification is optional.  That is not correct.  Anywhere that this    
  117    memo suggests that some action should be carried out, or must be        
  118    carried out, or that some behaviour is acceptable, or not, that is to   
  119    be considered as a fundamental aspect of this specification,            
  120    regardless of the specific words used.  If some behaviour or action     
  121    is truly optional, that will be clearly specified by the text.          
  123 4. Server Reply Source Address Selection                                   
  125    Most, if not all, DNS clients, expect the address from which a reply    
  126    is received to be the same address as that to which the query           
  127    eliciting the reply was sent.  This is true for servers acting as       
  128    clients for the purposes of recursive query resolution, as well as      
  129    simple resolver clients.  The address, along with the identifier (ID)   
  130    in the reply is used for disambiguating replies, and filtering          
  131    spurious responses.  This may, or may not, have been intended when      
  132    the DNS was designed, but is now a fact of life.                        
  134    Some multi-homed hosts running DNS servers generate a reply using a     
  135    source address that is not the same as the destination address from     
  136    the client's request packet.  Such replies will be discarded by the     
  137    client because the source address of the reply does not match that of   
  138    a host to which the client sent the original request.  That is, it      
  139    appears to be an unsolicited response.                                  
  141 4.1. UDP Source Address Selection                                          
  143    To avoid these problems, servers when responding to queries using UDP   
  144    must cause the reply to be sent with the source address field in the    
  145    IP header set to the address that was in the destination address        
  146    field of the IP header of the packet containing the query causing the   
  147    response.  If this would cause the response to be sent from an IP       
  148    address that is not permitted for this purpose, then the response may   
  149    be sent from any legal IP address allocated to the server.  That        
  150    address should be chosen to maximise the possibility that the client    
  151    will be able to use it for further queries.  Servers configured in      
  152    such a way that not all their addresses are equally reachable from      
  153    all potential clients need take particular care when responding to      
  154    queries sent to anycast, multicast, or similar, addresses.              
  162 Elz & Bush                  Standards Track                     [Page 3]   

  163 RFC 2181        Clarifications to the DNS Specification        July 1997   
  166 4.2. Port Number Selection                                                 
  168    Replies to all queries must be directed to the port from which they     
  169    were sent.  When queries are received via TCP this is an inherent       
  170    part of the transport protocol.  For queries received by UDP the        
  171    server must take note of the source port and use that as the            
  172    destination port in the response.  Replies should always be sent from   
  173    the port to which they were directed.  Except in extraordinary          
  174    circumstances, this will be the well known port assigned for DNS        
  175    queries [RFC1700].                                                      
  177 5. Resource Record Sets                                                    
  179    Each DNS Resource Record (RR) has a label, class, type, and data.  It   
  180    is meaningless for two records to ever have label, class, type and      
  181    data all equal - servers should suppress such duplicates if             
  182    encountered.  It is however possible for most record types to exist     
  183    with the same label, class and type, but with different data.  Such a   
  184    group of records is hereby defined to be a Resource Record Set          
  185    (RRSet).                                                                
  187 5.1. Sending RRs from an RRSet                                             
  189    A query for a specific (or non-specific) label, class, and type, will   
  190    always return all records in the associated RRSet - whether that be     
  191    one or more RRs.  The response must be marked as "truncated" if the     
  192    entire RRSet will not fit in the response.                              
  194 5.2. TTLs of RRs in an RRSet                                               
  196    Resource Records also have a time to live (TTL).  It is possible for    
  197    the RRs in an RRSet to have different TTLs.  No uses for this have      
  198    been found that cannot be better accomplished in other ways.  This      
  199    can, however, cause partial replies (not marked "truncated") from a     
  200    caching server, where the TTLs for some but not all the RRs in the      
  201    RRSet have expired.                                                     
  203    Consequently the use of differing TTLs in an RRSet is hereby            
  204    deprecated, the TTLs of all RRs in an RRSet must be the same.           
  206    Should a client receive a response containing RRs from an RRSet with    
  207    differing TTLs, it should treat this as an error.  If the RRSet         
  208    concerned is from a non-authoritative source for this data, the         
  209    client should simply ignore the RRSet, and if the values were           
  210    required, seek to acquire them from an authoritative source.  Clients   
  211    that are configured to send all queries to one, or more, particular     
  212    servers should treat those servers as authoritative for this purpose.   
  213    Should an authoritative source send such a malformed RRSet, the         
  217 Elz & Bush                  Standards Track                     [Page 4]   

  218 RFC 2181        Clarifications to the DNS Specification        July 1997   
  221    client should treat the RRs for all purposes as if all TTLs in the      
  222    RRSet had been set to the value of the lowest TTL in the RRSet.  In     
  223    no case may a server send an RRSet with TTLs not all equal.             
  225 5.3. DNSSEC Special Cases                                                  
  227    Two of the record types added by DNS Security (DNSSEC) [RFC2065]        
  228    require special attention when considering the formation of Resource    
  229    Record Sets.  Those are the SIG and NXT records.  It should be noted    
  230    that DNS Security is still very new, and there is, as yet, little       
  231    experience with it.  Readers should be prepared for the information     
  232    related to DNSSEC contained in this document to become outdated as      
  233    the DNS Security specification matures.                                 
  235 5.3.1. SIG records and RRSets                                              
  237    A SIG record provides signature (validation) data for another RRSet     
  238    in the DNS.  Where a zone has been signed, every RRSet in the zone      
  239    will have had a SIG record associated with it.  The data type of the    
  240    RRSet is included in the data of the SIG RR, to indicate with which     
  241    particular RRSet this SIG record is associated.  Were the rules above   
  242    applied, whenever a SIG record was included with a response to          
  243    validate that response, the SIG records for all other RRSets            
  244    associated with the appropriate node would also need to be included.    
  245    In some cases, this could be a very large number of records, not        
  246    helped by their being rather large RRs.                                 
  248    Thus, it is specifically permitted for the authority section to         
  249    contain only those SIG RRs with the "type covered" field equal to the   
  250    type field of an answer being returned.  However, where SIG records     
  251    are being returned in the answer section, in response to a query for    
  252    SIG records, or a query for all records associated with a name          
  253    (type=ANY) the entire SIG RRSet must be included, as for any other RR   
  254    type.                                                                   
  256    Servers that receive responses containing SIG records in the            
  257    authority section, or (probably incorrectly) as additional data, must   
  258    understand that the entire RRSet has almost certainly not been          
  259    included.  Thus, they must not cache that SIG record in a way that      
  260    would permit it to be returned should a query for SIG records be        
  261    received at that server.  RFC2065 actually requires that SIG queries    
  262    be directed only to authoritative servers to avoid the problems that    
  263    could be caused here, and while servers exist that do not understand    
  264    the special properties of SIG records, this will remain necessary.      
  265    However, careful design of SIG record processing in new                 
  266    implementations should permit this restriction to be relaxed in the     
  267    future, so resolvers do not need to treat SIG record queries            
  268    specially.                                                              
  272 Elz & Bush                  Standards Track                     [Page 5]   

  273 RFC 2181        Clarifications to the DNS Specification        July 1997   
  276    It has been occasionally stated that a received request for a SIG       
  277    record should be forwarded to an authoritative server, rather than      
  278    being answered from data in the cache.  This is not necessary - a       
  279    server that has the knowledge of SIG as a special case for processing   
  280    this way would be better to correctly cache SIG records, taking into    
  281    account their characteristics.  Then the server can determine when it   
  282    is safe to reply from the cache, and when the answer is not available   
  283    and the query must be forwarded.                                        
  285 5.3.2. NXT RRs                                                             
  287    Next Resource Records (NXT) are even more peculiar.  There will only    
  288    ever be one NXT record in a zone for a particular label, so             
  289    superficially, the RRSet problem is trivial.  However, at a zone cut,   
  290    both the parent zone, and the child zone (superzone and subzone in      
  291    RFC2065 terminology) will have NXT records for the same name.  Those    
  292    two NXT records do not form an RRSet, even where both zones are         
  293    housed at the same server.  NXT RRSets always contain just a single     
  294    RR.  Where both NXT records are visible, two RRSets exist.  However,    
  295    servers are not required to treat this as a special case when           
  296    receiving NXT records in a response.  They may elect to notice the      
  297    existence of two different NXT RRSets, and treat that as they would     
  298    two different RRSets of any other type.  That is, cache one, and        
  299    ignore the other.  Security aware servers will need to correctly        
  300    process the NXT record in the received response though.                 
  302 5.4. Receiving RRSets                                                      
  304    Servers must never merge RRs from a response with RRs in their cache    
  305    to form an RRSet.  If a response contains data that would form an       
  306    RRSet with data in a server's cache the server must either ignore the   
  307    RRs in the response, or discard the entire RRSet currently in the       
  308    cache, as appropriate.  Consequently the issue of TTLs varying          
  309    between the cache and a response does not cause concern, one will be    
  310    ignored.  That is, one of the data sets is always incorrect if the      
  311    data from an answer differs from the data in the cache.  The            
  312    challenge for the server is to determine which of the data sets is      
  313    correct, if one is, and retain that, while ignoring the other.  Note    
  314    that if a server receives an answer containing an RRSet that is         
  315    identical to that in its cache, with the possible exception of the      
  316    TTL value, it may, optionally, update the TTL in its cache with the     
  317    TTL of the received answer.  It should do this if the received answer   
  318    would be considered more authoritative (as discussed in the next        
  319    section) than the previously cached answer.                             
  327 Elz & Bush                  Standards Track                     [Page 6]   

  328 RFC 2181        Clarifications to the DNS Specification        July 1997   
  331 5.4.1. Ranking data                                                        
  333    When considering whether to accept an RRSet in a reply, or retain an    
  334    RRSet already in its cache instead, a server should consider the        
  335    relative likely trustworthiness of the various data.  An                
  336    authoritative answer from a reply should replace cached data that had   
  337    been obtained from additional information in an earlier reply.          
  338    However additional information from a reply will be ignored if the      
  339    cache contains data from an authoritative answer or a zone file.        
  341    The accuracy of data available is assumed from its source.              
  342    Trustworthiness shall be, in order from most to least:                  
  344      + Data from a primary zone file, other than glue data,                
  345      + Data from a zone transfer, other than glue,                         
  346      + The authoritative data included in the answer section of an         
  347        authoritative reply.                                                
  348      + Data from the authority section of an authoritative answer,         
  349      + Glue from a primary zone, or glue from a zone transfer,             
  350      + Data from the answer section of a non-authoritative answer, and     
  351        non-authoritative data from the answer section of authoritative     
  352        answers,                                                            
  353      + Additional information from an authoritative answer,                
  354        Data from the authority section of a non-authoritative answer,      
  355        Additional information from non-authoritative answers.              
  357    Note that the answer section of an authoritative answer normally        
  358    contains only authoritative data.  However when the name sought is an   
  359    alias (see section 10.1.1) only the record describing that alias is     
  360    necessarily authoritative.  Clients should assume that other records    
  361    may have come from the server's cache.  Where authoritative answers     
  362    are required, the client should query again, using the canonical name   
  363    associated with the alias.                                              
  365    Unauthenticated RRs received and cached from the least trustworthy of   
  366    those groupings, that is data from the additional data section, and     
  367    data from the authority section of a non-authoritative answer, should   
  368    not be cached in such a way that they would ever be returned as         
  369    answers to a received query.  They may be returned as additional        
  370    information where appropriate.  Ignoring this would allow the           
  371    trustworthiness of relatively untrustworthy data to be increased        
  372    without cause or excuse.                                                
  374    When DNS security [RFC2065] is in use, and an authenticated reply has   
  375    been received and verified, the data thus authenticated shall be        
  376    considered more trustworthy than unauthenticated data of the same       
  377    type.  Note that throughout this document, "authoritative" means a      
  378    reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY   
  382 Elz & Bush                  Standards Track                     [Page 7]   

  383 RFC 2181        Clarifications to the DNS Specification        July 1997   
  386    records to determine the authenticity of data, the AA bit is almost     
  387    irrelevant.  However DNSSEC aware servers must still correctly set      
  388    the AA bit in responses to enable correct operation with servers that   
  389    are not security aware (almost all currently).                          
  391    Note that, glue excluded, it is impossible for data from two            
  392    correctly configured primary zone files, two correctly configured       
  393    secondary zones (data from zone transfers) or data from correctly       
  394    configured primary and secondary zones to ever conflict.  Where glue    
  395    for the same name exists in multiple zones, and differs in value, the   
  396    nameserver should select data from a primary zone file in preference    
  397    to secondary, but otherwise may choose any single set of such data.     
  398    Choosing that which appears to come from a source nearer the            
  399    authoritative data source may make sense where that can be              
  400    determined.  Choosing primary data over secondary allows the source     
  401    of incorrect glue data to be discovered more readily, when a problem    
  402    with such data exists.  Where a server can detect from two zone files   
  403    that one or more are incorrectly configured, so as to create            
  404    conflicts, it should refuse to load the zones determined to be          
  405    erroneous, and issue suitable diagnostics.                              
  407    "Glue" above includes any record in a zone file that is not properly    
  408    part of that zone, including nameserver records of delegated sub-       
  409    zones (NS records), address records that accompany those NS records     
  410    (A, AAAA, etc), and any other stray data that might appear.             
  412 5.5. Sending RRSets (reprise)                                              
  414    A Resource Record Set should only be included once in any DNS reply.    
  415    It may occur in any of the Answer, Authority, or Additional             
  416    Information sections, as required.  However it should not be repeated   
  417    in the same, or any other, section, except where explicitly required    
  418    by a specification.  For example, an AXFR response requires the SOA     
  419    record (always an RRSet containing a single RR) be both the first and   
  420    last record of the reply.  Where duplicates are required this way,      
  421    the TTL transmitted in each case must be the same.                      
  423 6. Zone Cuts                                                               
  425    The DNS tree is divided into "zones", which are collections of          
  426    domains that are treated as a unit for certain management purposes.     
  427    Zones are delimited by "zone cuts".  Each zone cut separates a          
  428    "child" zone (below the cut) from a "parent" zone (above the cut).      
  429    The domain name that appears at the top of a zone (just below the cut   
  430    that separates the zone from its parent) is called the zone's           
  431    "origin".  The name of the zone is the same as the name of the domain   
  432    at the zone's origin.  Each zone comprises that subset of the DNS       
  433    tree that is at or below the zone's origin, and that is above the       
  437 Elz & Bush                  Standards Track                     [Page 8]   

  438 RFC 2181        Clarifications to the DNS Specification        July 1997   
  441    cuts that separate the zone from its children (if any).  The            
  442    existence of a zone cut is indicated in the parent zone by the          
  443    existence of NS records specifying the origin of the child zone.  A     
  444    child zone does not contain any explicit reference to its parent.       
  446 6.1. Zone authority                                                        
  448    The authoritative servers for a zone are enumerated in the NS records   
  449    for the origin of the zone, which, along with a Start of Authority      
  450    (SOA) record are the mandatory records in every zone.  Such a server    
  451    is authoritative for all resource records in a zone that are not in     
  452    another zone.  The NS records that indicate a zone cut are the          
  453    property of the child zone created, as are any other records for the    
  454    origin of that child zone, or any sub-domains of it.  A server for a    
  455    zone should not return authoritative answers for queries related to     
  456    names in another zone, which includes the NS, and perhaps A, records    
  457    at a zone cut, unless it also happens to be a server for the other      
  458    zone.                                                                   
  460    Other than the DNSSEC cases mentioned immediately below, servers        
  461    should ignore data other than NS records, and necessary A records to    
  462    locate the servers listed in the NS records, that may happen to be      
  463    configured in a zone at a zone cut.                                     
  465 6.2. DNSSEC issues                                                         
  467    The DNS security mechanisms [RFC2065] complicate this somewhat, as      
  468    some of the new resource record types added are very unusual when       
  469    compared with other DNS RRs.  In particular the NXT ("next") RR type    
  470    contains information about which names exist in a zone, and hence       
  471    which do not, and thus must necessarily relate to the zone in which     
  472    it exists.  The same domain name may have different NXT records in      
  473    the parent zone and the child zone, and both are valid, and are not     
  474    an RRSet.  See also section 5.3.2.                                      
  476    Since NXT records are intended to be automatically generated, rather    
  477    than configured by DNS operators, servers may, but are not required     
  478    to, retain all differing NXT records they receive regardless of the     
  479    rules in section 5.4.                                                   
  481    For a secure parent zone to securely indicate that a subzone is         
  482    insecure, DNSSEC requires that a KEY RR indicating that the subzone     
  483    is insecure, and the parent zone's authenticating SIG RR(s) be          
  484    present in the parent zone, as they by definition cannot be in the      
  485    subzone.  Where a subzone is secure, the KEY and SIG records will be    
  486    present, and authoritative, in that zone, but should also always be     
  487    present in the parent zone (if secure).                                 
  492 Elz & Bush                  Standards Track                     [Page 9]   

  493 RFC 2181        Clarifications to the DNS Specification        July 1997   
  496    Note that in none of these cases should a server for the parent zone,   
  497    not also being a server for the subzone, set the AA bit in any          
  498    response for a label at a zone cut.                                     
  500 7. SOA RRs                                                                 
  502    Three minor issues concerning the Start of Zone of Authority (SOA)      
  503    Resource Record need some clarification.                                
  505 7.1. Placement of SOA RRs in authoritative answers                         
  507    RFC1034, in section 3.7, indicates that the authority section of an     
  508    authoritative answer may contain the SOA record for the zone from       
  509    which the answer was obtained.  When discussing negative caching,       
  510    RFC1034 section 4.3.4 refers to this technique but mentions the         
  511    additional section of the response.  The former is correct, as is       
  512    implied by the example shown in section 6.2.5 of RFC1034.  SOA          
  513    records, if added, are to be placed in the authority section.           
  515 7.2. TTLs on SOA RRs                                                       
  517    It may be observed that in section 3.2.1 of RFC1035, which defines      
  518    the format of a Resource Record, that the definition of the TTL field   
  519    contains a throw away line which states that the TTL of an SOA record   
  520    should always be sent as zero to prevent caching.  This is mentioned    
  521    nowhere else, and has not generally been implemented.                   
  522    Implementations should not assume that SOA records will have a TTL of   
  523    zero, nor are they required to send SOA records with a TTL of zero.     
  525 7.3. The SOA.MNAME field                                                   
  527    It is quite clear in the specifications, yet seems to have been         
  528    widely ignored, that the MNAME field of the SOA record should contain   
  529    the name of the primary (master) server for the zone identified by      
  530    the SOA.  It should not contain the name of the zone itself.  That      
  531    information would be useless, as to discover it, one needs to start     
  532    with the domain name of the SOA record - that is the name of the        
  533    zone.                                                                   

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 Robert Edmonds(Technical Erratum #6446) [Reported]
based on outdated version
It should say:

Sections 1, 5, 6, and 10 consistently use the term "label" to incorrectly refer to what STD 13 calls an "owner". There may also be additional instances of "label" being used incorrectly in Section 11.
GLOBAL V. Risk, ISC.orgBIND 9 implementation note2022-08-15

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

  535 8. Time to Live (TTL)                                                      
  537    The definition of values appropriate to the TTL field in STD 13 is      
  538    not as clear as it could be, with respect to how many significant       
  539    bits exist, and whether the value is signed or unsigned.  It is         
  540    hereby specified that a TTL value is an unsigned number, with a         
  541    minimum value of 0, and a maximum value of 2147483647.  That is, a      
  542    maximum of 2^31 - 1.  When transmitted, this value shall be encoded     
  543    in the less significant 31 bits of the 32 bit TTL field, with the       
  547 Elz & Bush                  Standards Track                    [Page 10]   

  548 RFC 2181        Clarifications to the DNS Specification        July 1997   
  551    most significant, or sign, bit set to zero.                             
  553    Implementations should treat TTL values received with the most          
  554    significant bit set as if the entire value received was zero.           
  556    Implementations are always free to place an upper bound on any TTL      
  557    received, and treat any larger values as if they were that upper        
  558    bound.  The TTL specifies a maximum time to live, not a mandatory       
  559    time to live.                                                           
  561 9. The TC (truncated) header bit                                           
  563    The TC bit should be set in responses only when an RRSet is required    
  564    as a part of the response, but could not be included in its entirety.   
  565    The TC bit should not be set merely because some extra information      
  566    could have been included, but there was insufficient room.  This        
  567    includes the results of additional section processing.  In such cases   
  568    the entire RRSet that will not fit in the response should be omitted,   
  569    and the reply sent as is, with the TC bit clear.  If the recipient of   
  570    the reply needs the omitted data, it can construct a query for that     
  571    data and send that separately.                                          
  573    Where TC is set, the partial RRSet that would not completely fit may    
  574    be left in the response.  When a DNS client receives a reply with TC    
  575    set, it should ignore that response, and query again, using a           
  576    mechanism, such as a TCP connection, that will permit larger replies.   
  578 10. Naming issues                                                          
  580    It has sometimes been inferred from some sections of the DNS            
  581    specification [RFC1034, RFC1035] that a host, or perhaps an interface   
  582    of a host, is permitted exactly one authoritative, or official, name,   
  583    called the canonical name.  There is no such requirement in the DNS.    
  585 10.1. CNAME resource records                                               
  587    The DNS CNAME ("canonical name") record exists to provide the           
  588    canonical name associated with an alias name.  There may be only one    
  589    such canonical name for any one alias.  That name should generally be   
  590    a name that exists elsewhere in the DNS, though there are some rare     
  591    applications for aliases with the accompanying canonical name           
  592    undefined in the DNS.  An alias name (label of a CNAME record) may,     
  593    if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no        
  594    other data.  That is, for any label in the DNS (any domain name)        
  595    exactly one of the following is true:                                   
  602 Elz & Bush                  Standards Track                    [Page 11]   

  603 RFC 2181        Clarifications to the DNS Specification        July 1997   
  606      + one CNAME record exists, optionally accompanied by SIG, NXT, and    
  607        KEY RRs,                                                            
  608      + one or more records exist, none being CNAME records,                
  609      + the name exists, but has no associated RRs of any type,             
  610      + the name does not exist at all.                                     
  612 10.1.1. CNAME terminology                                                  
  614    It has been traditional to refer to the label of a CNAME record as "a   
  615    CNAME".  This is unfortunate, as "CNAME" is an abbreviation of          
  616    "canonical name", and the label of a CNAME record is most certainly     
  617    not a canonical name.  It is, however, an entrenched usage.  Care       
  618    must therefore be taken to be very clear whether the label, or the      
  619    value (the canonical name) of a CNAME resource record is intended.      
  620    In this document, the label of a CNAME resource record will always be   
  621    referred to as an alias.                                                
  623 10.2. PTR records                                                          
  625    Confusion about canonical names has lead to a belief that a PTR         
  626    record should have exactly one RR in its RRSet.  This is incorrect,     
  627    the relevant section of RFC1034 (section 3.6.2) indicates that the      
  628    value of a PTR record should be a canonical name.  That is, it should   
  629    not be an alias.  There is no implication in that section that only     
  630    one PTR record is permitted for a name.  No such restriction should     
  631    be inferred.                                                            
  633    Note that while the value of a PTR record must not be an alias, there   
  634    is no requirement that the process of resolving a PTR record not        
  635    encounter any aliases.  The label that is being looked up for a PTR     
  636    value might have a CNAME record.  That is, it might be an alias.  The   
  637    value of that CNAME RR, if not another alias, which it should not be,   
  638    will give the location where the PTR record is found.  That record      
  639    gives the result of the PTR type lookup.  This final result, the        
  640    value of the PTR RR, is the label which must not be an alias.           
  642 10.3. MX and NS records                                                    
  644    The domain name used as the value of a NS resource record, or part of   
  645    the value of a MX resource record must not be an alias.  Not only is    
  646    the specification clear on this point, but using an alias in either     
  647    of these positions neither works as well as might be hoped, nor well    
  648    fulfills the ambition that may have led to this approach.  This         
  649    domain name must have as its value one or more address records.         
  650    Currently those will be A records, however in the future other record   
  651    types giving addressing information may be acceptable.  It can also     
  652    have other RRs, but never a CNAME RR.                                   
  657 Elz & Bush                  Standards Track                    [Page 12]   

  658 RFC 2181        Clarifications to the DNS Specification        July 1997   
  661    Searching for either NS or MX records causes "additional section        
  662    processing" in which address records associated with the value of the   
  663    record sought are appended to the answer.  This helps avoid needless    
  664    extra queries that are easily anticipated when the first was made.      
  666    Additional section processing does not include CNAME records, let       
  667    alone the address records that may be associated with the canonical     
  668    name derived from the alias.  Thus, if an alias is used as the value    
  669    of an NS or MX record, no address will be returned with the NS or MX    
  670    value.  This can cause extra queries, and extra network burden, on      
  671    every query.  It is trivial for the DNS administrator to avoid this     
  672    by resolving the alias and placing the canonical name directly in the   
  673    affected record just once when it is updated or installed.  In some     
  674    particular hard cases the lack of the additional section address        
  675    records in the results of a NS lookup can cause the request to fail.    
  677 11. Name syntax                                                            
  679    Occasionally it is assumed that the Domain Name System serves only      
  680    the purpose of mapping Internet host names to data, and mapping         
  681    Internet addresses to host names.  This is not correct, the DNS is a    
  682    general (if somewhat limited) hierarchical database, and can store      
  683    almost any kind of data, for almost any purpose.                        
  685    The DNS itself places only one restriction on the particular labels     
  686    that can be used to identify resource records.  That one restriction    
  687    relates to the length of the label and the full name.  The length of    
  688    any one label is limited to between 1 and 63 octets.  A full domain     
  689    name is limited to 255 octets (including the separators).  The zero     
  690    length full name is defined as representing the root of the DNS tree,   
  691    and is typically written and displayed as ".".  Those restrictions      
  692    aside, any binary string whatever can be used as the label of any       
  693    resource record.  Similarly, any binary string can serve as the value   
  694    of any record that includes a domain name as some or all of its value   
  695    (SOA, NS, MX, PTR, CNAME, and any others that may be added).            
  696    Implementations of the DNS protocols must not place any restrictions    
  697    on the labels that can be used.  In particular, DNS servers must not    
  698    refuse to serve a zone because it contains labels that might not be     
  699    acceptable to some DNS client programs.  A DNS server may be            
  700    configurable to issue warnings when loading, or even to refuse to       
  701    load, a primary zone containing labels that might be considered         
  702    questionable, however this should not happen by default.                
  704    Note however, that the various applications that make use of DNS data   
  705    can have restrictions imposed on what particular values are             
  706    acceptable in their environment.  For example, that any binary label    
  707    can have an MX record does not imply that any binary name can be used   
  708    as the host part of an e-mail address.  Clients of the DNS can impose   
  712 Elz & Bush                  Standards Track                    [Page 13]   

  713 RFC 2181        Clarifications to the DNS Specification        July 1997   
  716    whatever restrictions are appropriate to their circumstances on the     
  717    values they use as keys for DNS lookup requests, and on the values      
  718    returned by the DNS.  If the client has such restrictions, it is        
  719    solely responsible for validating the data from the DNS to ensure       
  720    that it conforms before it makes any use of that data.                  
  722    See also [RFC1123] section                                     
  724 12. Security Considerations                                                
  726    This document does not consider security.                               
  728    In particular, nothing in section 4 is any way related to, or useful    
  729    for, any security related purposes.                                     
  731    Section 5.4.1 is also not related to security.  Security of DNS data    
  732    will be obtained by the Secure DNS [RFC2065], which is mostly           
  733    orthogonal to this memo.                                                
  735    It is not believed that anything in this document adds to any           
  736    security issues that may exist with the DNS, nor does it do anything    
  737    to that will necessarily lessen them.  Correct implementation of the    
  738    clarifications in this document might play some small part in           
  739    limiting the spread of non-malicious bad data in the DNS, but only      
  740    DNSSEC can help with deliberate attempts to subvert DNS data.           
  742 13. References                                                             
  744    [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",  
  745                STD 13, RFC 1034, November 1987.                            
  747    [RFC1035]   Mockapetris, P., "Domain Names - Implementation and         
  748                Specification", STD 13, RFC 1035, November 1987.            
  750    [RFC1123]   Braden, R., "Requirements for Internet Hosts - application  
  751                and support", STD 3, RFC 1123, January 1989.                
  753    [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",               
  754                STD 2, RFC 1700, October 1994.                              
  756    [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security     
  757                Extensions", RFC 2065, January 1997.                        
  767 Elz & Bush                  Standards Track                    [Page 14]   

  768 RFC 2181        Clarifications to the DNS Specification        July 1997   
  771 14. Acknowledgements                                                       
  773    This memo arose from discussions in the DNSIND working group of the     
  774    IETF in 1995 and 1996, the members of that working group are largely    
  775    responsible for the ideas captured herein.  Particular thanks to        
  776    Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the      
  777    DNSSEC issues in this document, and to John Gilmore for pointing out    
  778    where the clarifications were not necessarily clarifying.  Bob Halley   
  779    suggested clarifying the placement of SOA records in authoritative      
  780    answers, and provided the references.  Michael Patton, as usual, and    
  781    Mark Andrews, Alan Barrett and Stan Barber provided much assistance     
  782    with many details.  Josh Littlefield helped make sure that the          
  783    clarifications didn't cause problems in some irritating corner cases.   
  785 15. Authors' Addresses                                                     
  787    Robert Elz                                                              
  788    Computer Science                                                        
  789    University of Melbourne                                                 
  790    Parkville, Victoria, 3052                                               
  791    Australia.                                                              
  793    EMail: kre@munnari.OZ.AU                                                
  796    Randy Bush                                                              
  797    RGnet, Inc.                                                             
  798    5147 Crystal Springs Drive NE                                           
  799    Bainbridge Island, Washington,  98110                                   
  800    United States.                                                          
  802    EMail: randy@psg.com                                                    
  822 Elz & Bush                  Standards Track                    [Page 15]   

All of RFC8767 touches on aspects of how TTLs are calculated and used by resolvers. In particular, RFC 8767 says that it "updates RFC 2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days".

The last paragraph of Section 3 in RFC4034 updates the TTL rules, specifically for RRSIG records. It says:

The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
covers.  This is an exception to the [RFC2181] rules for TTL values
of individual RRs within a RRset: individual RRSIG RRs with the same
owner name will have different TTL values if the RRsets they cover
have different TTL values.

This is also mentioned briefly in RFC4035.