1 Internet Engineering Task Force (IETF)                           S. Rose   
    2 Request for Comments: 6672                                          NIST   
    3 Obsoletes: 2672                                            W. Wijngaards   
    4 Updates: 3363                                                 NLnet Labs   
    5 Category: Standards Track                                      June 2012   
    6 ISSN: 2070-1721                                                            
    7                                                                            
    8                                                                            
    9                       DNAME Redirection in the DNS                         
   10                                                                            
   11 Abstract                                                                   
   12                                                                            
   13    The DNAME record provides redirection for a subtree of the domain       
   14    name tree in the DNS.  That is, all names that end with a particular    
   15    suffix are redirected to another part of the DNS.  This document        
   16    obsoletes the original specification in RFC 2672 as well as updates     
   17    the document on representing IPv6 addresses in DNS (RFC 3363).          
   18                                                                            
   19 Status of This Memo                                                        
   20                                                                            
   21    This is an Internet Standards Track document.                           
   22                                                                            
   23    This document is a product of the Internet Engineering Task Force       
   24    (IETF).  It represents the consensus of the IETF community.  It has     
   25    received public review and has been approved for publication by the     
   26    Internet Engineering Steering Group (IESG).  Further information on     
   27    Internet Standards is available in Section 2 of RFC 5741.               
   28                                                                            
   29    Information about the current status of this document, any errata,      
   30    and how to provide feedback on it may be obtained at                    
   31    http://www.rfc-editor.org/info/rfc6672.                                 
   32                                                                            
   33                                                                            
   34                                                                            
   35                                                                            
   36                                                                            
   37                                                                            
   38                                                                            
   39                                                                            
   40                                                                            
   41                                                                            
   42                                                                            
   43                                                                            
   44                                                                            
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Rose & Wijngaards            Standards Track                    [Page 1]   

   53 RFC 6672                    DNAME Redirection                  June 2012   
   54                                                                            
   55                                                                            
   56 Copyright Notice                                                           
   57                                                                            
   58    Copyright (c) 2012 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   60                                                                            
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (http://trustee.ietf.org/license-info) in effect on the date of         
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   70                                                                            
   71    This document may contain material from IETF Documents or IETF          
   72    Contributions published or made publicly available before November      
   73    10, 2008.  The person(s) controlling the copyright in some of this      
   74    material may not have granted the IETF Trust the right to allow         
   75    modifications of such material outside the IETF Standards Process.      
   76    Without obtaining an adequate license from the person(s) controlling    
   77    the copyright in such materials, this document may not be modified      
   78    outside the IETF Standards Process, and derivative works of it may      
   79    not be created outside the IETF Standards Process, except to format     
   80    it for publication as an RFC or to translate it into languages other    
   81    than English.                                                           
   82                                                                            
   83                                                                            
   84                                                                            
   85                                                                            
   86                                                                            
   87                                                                            
   88                                                                            
   89                                                                            
   90                                                                            
   91                                                                            
   92                                                                            
   93                                                                            
   94                                                                            
   95                                                                            
   96                                                                            
   97                                                                            
   98                                                                            
   99                                                                            
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Rose & Wijngaards            Standards Track                    [Page 2]   

  108 RFC 6672                    DNAME Redirection                  June 2012   
  109                                                                            
  110                                                                            
  111 Table of Contents                                                          
  112                                                                            
  113    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4   
  114      1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4   
  115    2.  The DNAME Resource Record  . . . . . . . . . . . . . . . . . .  5   
  116      2.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  5   
  117      2.2.  The DNAME Substitution . . . . . . . . . . . . . . . . . .  5   
  118      2.3.  DNAME Owner Name Matching the QNAME  . . . . . . . . . . .  6   
  119      2.4.  Names next to and below a DNAME Record . . . . . . . . . .  7   
  120      2.5.  Compression of the DNAME Record  . . . . . . . . . . . . .  7   
  121    3.  Processing . . . . . . . . . . . . . . . . . . . . . . . . . .  8   
  122      3.1.  CNAME Synthesis  . . . . . . . . . . . . . . . . . . . . .  8   
  123      3.2.  Server Algorithm . . . . . . . . . . . . . . . . . . . . .  9   
  124      3.3.  Wildcards  . . . . . . . . . . . . . . . . . . . . . . . . 10   
  125      3.4.  Acceptance and Intermediate Storage  . . . . . . . . . . . 11   
  126        3.4.1.  Resolver Algorithm . . . . . . . . . . . . . . . . . . 11   
  127    4.  DNAME Discussions in Other Documents . . . . . . . . . . . . . 12   
  128    5.  Other Issues with DNAME  . . . . . . . . . . . . . . . . . . . 13   
  129      5.1.  Canonical Hostnames Cannot Be below DNAME Owners . . . . . 13   
  130      5.2.  Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13   
  131      5.3.  DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 14   
  132        5.3.1.  Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14   
  133        5.3.2.  DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14   
  134        5.3.3.  DNAME Chains as Strong as the Weakest Link . . . . . . 14   
  135        5.3.4.  Validators Must Understand DNAME . . . . . . . . . . . 14   
  136          5.3.4.1.  Invalid Name Error Response Caused by DNAME in          
  137                    Bitmap . . . . . . . . . . . . . . . . . . . . . . 15   
  138          5.3.4.2.  Valid Name Error Response Involving DNAME in            
  139                    Bitmap . . . . . . . . . . . . . . . . . . . . . . 15   
  140          5.3.4.3.  Response with Synthesized CNAME  . . . . . . . . . 16   
  141    6.  Examples of DNAME Use in a Zone  . . . . . . . . . . . . . . . 16   
  142      6.1.  Organizational Renaming  . . . . . . . . . . . . . . . . . 16   
  143      6.2.  Classless Delegation of Shorter Prefixes . . . . . . . . . 17   
  144      6.3.  Network Renumbering Support  . . . . . . . . . . . . . . . 17   
  145    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18   
  146    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18   
  147    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18   
  148    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19   
  149      10.1. Normative References . . . . . . . . . . . . . . . . . . . 19   
  150      10.2. Informative References . . . . . . . . . . . . . . . . . . 20   
  151    Appendix A.  Changes from RFC 2672 . . . . . . . . . . . . . . . . 21   
  152      A.1.  Changes to Server Behavior . . . . . . . . . . . . . . . . 21   
  153      A.2.  Changes to Client Behavior . . . . . . . . . . . . . . . . 21   
  154                                                                            
  155                                                                            
  156                                                                            
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Rose & Wijngaards            Standards Track                    [Page 3]   

  163 RFC 6672                    DNAME Redirection                  June 2012   
  164                                                                            
  165                                                                            
  166 1.  Introduction                                                           
  167                                                                            
  168    DNAME is a DNS resource record type originally defined in RFC 2672      
  169    [RFC2672].  DNAME provides redirection from a part of the DNS name      
  170    tree to another part of the DNS name tree.                              
  171                                                                            
  172    The DNAME RR and the CNAME RR [RFC1034] cause a lookup to               
  173    (potentially) return data corresponding to a domain name different      
  174    from the queried domain name.  The difference between the two           
  175    resource records is that the CNAME RR directs the lookup of data at     
  176    its owner to another single name, whereas a DNAME RR directs lookups    
  177    for data at descendants of its owner's name to corresponding names      
  178    under a different (single) node of the tree.                            
  179                                                                            
  180    For example, take looking through a zone (see RFC 1034 [RFC1034],       
  181    Section 4.3.2, step 3) for the domain name "foo.example.com", and a     
  182    DNAME resource record is found at "example.com" indicating that all     
  183    queries under "example.com" be directed to "example.net".  The lookup   
  184    process will return to step 1 with the new query name of                
  185    "foo.example.net".  Had the query name been "www.foo.example.com",      
  186    the new query name would be "www.foo.example.net".                      
  187                                                                            
  188    This document is a revision of the original specification of DNAME in   
  189    RFC 2672 [RFC2672].  DNAME was conceived to help with the problem of    
  190    maintaining address-to-name mappings in a context of network            
  191    renumbering.  With a careful setup, a renumbering event in the          
  192    network causes no change to the authoritative server that has the       
  193    address-to-name mappings.  Examples in practice are classless reverse   
  194    address space delegations.                                              
  195                                                                            
  196    Another usage of DNAME lies in aliasing of name spaces.  For example,   
  197    a zone administrator may want subtrees of the DNS to contain the same   
  198    information.  Examples include punycode [RFC3492] alternates for        
  199    domain spaces.                                                          
  200                                                                            
  201    This revision of the DNAME specification does not change the wire       
  202    format or the handling of DNAME resource records.  Discussion is        
  203    added on problems that may be encountered when using DNAME.             
  204                                                                            
  205 1.1.  Requirements Language                                                
  206                                                                            
  207    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  208    "SHOULD", "SHOULD NOT", "RECOMMENDED" "NOT RECOMMENDED", "MAY", and     
  209    "OPTIONAL" in this document are to be interpreted as described in RFC   
  210    2119 [RFC2119].                                                         
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Rose & Wijngaards            Standards Track                    [Page 4]   

  218 RFC 6672                    DNAME Redirection                  June 2012   
  219                                                                            
  220                                                                            
  221 2.  The DNAME Resource Record                                              
  222                                                                            
  223 2.1.  Format                                                               
  224                                                                            
  225    The DNAME RR has mnemonic DNAME and type code 39 (decimal).  It is      
  226    CLASS-insensitive.                                                      
  227                                                                            
  228    Its RDATA is comprised of a single field, <target>, which contains a    
  229    fully qualified domain name that MUST be sent in uncompressed form      
  230    [RFC1035] [RFC3597].  The <target> field MUST be present.  The          
  231    presentation format of <target> is that of a domain name [RFC1035].     
  232    The presentation format of the RR is as follows:                        
  233                                                                            
  234            <owner> <ttl> <class> DNAME <target>                            
  235                                                                            
  236    The effect of the DNAME RR is the substitution of the record's          
  237    <target> for its owner name, as a suffix of a domain name.  This        
  238    substitution is to be applied for all names below the owner name of     
  239    the DNAME RR.  This substitution has to be applied for every DNAME RR   
  240    found in the resolution process, which allows fairly lengthy valid      
  241    chains of DNAME RRs.                                                    
  242                                                                            
  243    Details of the substitution process, methods to avoid conflicting       
  244    resource records, and rules for specific corner cases are given in      
  245    the following subsections.                                              
  246                                                                            
  247 2.2.  The DNAME Substitution                                               
  248                                                                            
  249    When following step 3 of the algorithm in RFC 1034 [RFC1034], Section   
  250    4.3.2, "start matching down, label by label, in the zone" and a node    
  251    is found to own a DNAME resource record, a DNAME substitution occurs.   
  252    The name being sought may be the original query name or a name that     
  253    is the result of a CNAME resource record being followed or a            
  254    previously encountered DNAME.  As in the case when finding a CNAME      
  255    resource record or NS resource record set, the processing of a DNAME    
  256    will happen prior to finding the desired domain name.                   
  257                                                                            
  258    A DNAME substitution is performed by replacing the suffix labels of     
  259    the name being sought matching the owner name of the DNAME resource     
  260    record with the string of labels in the RDATA field.  The matching      
  261    labels end with the root label in all cases.  Only whole labels are     
  262    replaced.  See the table of examples for common cases and corner        
  263    cases.                                                                  
  264                                                                            
  265    In the table below, the QNAME refers to the query name.  The owner is   
  266    the DNAME owner domain name, and the target refers to the target of     
  267    the DNAME record.  The result is the resulting name after performing    
  268    the DNAME substitution on the query name. "no match" means that the     
  269                                                                            
  270                                                                            
  271                                                                            
  272 Rose & Wijngaards            Standards Track                    [Page 5]   

  273 RFC 6672                    DNAME Redirection                  June 2012   
  274                                                                            
  275                                                                            
  276    query did not match the DNAME, and thus no substitution is performed    
  277    and a possible error message is returned (if no other result is         
  278    possible).  Thus, every line contains one example substitution.  In     
  279    the examples below, 'cyc' and 'shortloop' contain loops.                
  280                                                                            
  281     QNAME            owner  DNAME   target         result                  
  282     ---------------- -------------- -------------- -----------------       
  283     com.             example.com.   example.net.   <no match>              
  284     example.com.     example.com.   example.net.   [0]                     
  285     a.example.com.   example.com.   example.net.   a.example.net.          
  286     a.b.example.com. example.com.   example.net.   a.b.example.net.        
  287     ab.example.com.  b.example.com. example.net.   <no match>              
  288     foo.example.com. example.com.   example.net.   foo.example.net.        
  289     a.x.example.com. x.example.com. example.net.   a.example.net.          
  290     a.example.com.   example.com.   y.example.net. a.y.example.net.        
  291     cyc.example.com. example.com.   example.com.   cyc.example.com.        
  292     cyc.example.com. example.com.   c.example.com. cyc.c.example.com.      
  293     shortloop.x.x.   x.             .              shortloop.x.            
  294     shortloop.x.     x.             .              shortloop.              
  295                                                                            
  296    [0] The result depends on the QTYPE.  If the QTYPE = DNAME, then        
  297        the result is "example.com.", else "<no match>".                    
  298                                                                            
  299                    Table 1. DNAME Substitution Examples                    
  300                                                                            
  301    It is possible for DNAMEs to form loops, just as CNAMEs can form        
  302    loops.  DNAMEs and CNAMEs can chain together to form loops.  A single   
  303    corner case DNAME can form a loop.  Resolvers and servers should be     
  304    cautious in devoting resources to a query, but be aware that fairly     
  305    long chains of DNAMEs may be valid.  Zone content administrators        
  306    should take care to ensure that there are no loops that could occur     
  307    when using DNAME or DNAME/CNAME redirection.                            
  308                                                                            
  309    The domain name can get too long during substitution.  For example,     
  310    suppose the target name of the DNAME RR is 250 octets in length         
  311    (multiple labels), if an incoming QNAME that has a first label over 5   
  312    octets in length, the result would be a name over 255 octets.  If       
  313    this occurs, the server returns an RCODE of YXDOMAIN [RFC2136].  The    
  314    DNAME record and its signature (if the zone is signed) are included     
  315    in the answer as proof for the YXDOMAIN (value 6) RCODE.                
  316                                                                            
  317 2.3.  DNAME Owner Name Matching the QNAME                                  
  318                                                                            
  319    Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its    
  320    owner name; the owner name of a DNAME is not redirected itself.  The    
  321    domain name that owns a DNAME record is allowed to have other           
  322    resource record types at that domain name, except DNAMEs, CNAMEs, or    
  323    other types that have restrictions on what they can coexist with.       
  324                                                                            
  325                                                                            
  326                                                                            
  327 Rose & Wijngaards            Standards Track                    [Page 6]   

  328 RFC 6672                    DNAME Redirection                  June 2012   
  329                                                                            
  330                                                                            
  331    When there is a match of the QTYPE to a type (or types) also owned by   
  332    the owner name, the response is sourced from the owner name.  For       
  333    example, a QTYPE of ANY would return the (available) types at the       
  334    owner name, not the target name.                                        
  335                                                                            
  336    DNAME RRs MUST NOT appear at the same owner name as an NS RR unless     
  337    the owner name is the zone apex; if it is not the zone apex, then the   
  338    NS RR signifies a delegation point, and the DNAME RR must in that       
  339    case appear below the zone cut at the zone apex of the child zone.      
  340                                                                            
  341    If a DNAME record is present at the zone apex, there is still a need    
  342    to have the customary SOA and NS resource records there as well.        
  343    Such a DNAME cannot be used to mirror a zone completely, as it does     
  344    not mirror the zone apex.                                               
  345                                                                            
  346    These rules also allow DNAME records to be queried through caches       
  347    that are RFC 1034 [RFC1034] compliant and are DNAME unaware.            
  348                                                                            
  349 2.4.  Names next to and below a DNAME Record                               
  350                                                                            
  351    Resource records MUST NOT exist at any subdomain of the owner of a      
  352    DNAME RR.  To get the contents for names subordinate to that owner      
  353    name, the DNAME redirection must be invoked and the resulting target    
  354    queried.  A server MAY refuse to load a zone that has data at a         
  355    subdomain of a domain name owning a DNAME RR.  If the server does       
  356    load the zone, those names below the DNAME RR will be occluded as       
  357    described in RFC 2136 [RFC2136], Section 7.18.  Also, a server ought    
  358    to refuse to load a zone subordinate to the owner of a DNAME record     
  359    in the ancestor zone.  See Section 5.2 for further discussion related   
  360    to dynamic update.                                                      
  361                                                                            
  362    DNAME is a singleton type, meaning only one DNAME is allowed per        
  363    name.  The owner name of a DNAME can only have one DNAME RR, and no     
  364    CNAME RRs can exist at that name.  These rules make sure that for a     
  365    single domain name, only one redirection exists; thus, there's no       
  366    confusion about which one to follow.  A server ought to refuse to       
  367    load a zone that violates these rules.                                  
  368                                                                            
  369 2.5.  Compression of the DNAME Record                                      
  370                                                                            
  371    The DNAME owner name can be compressed like any other owner name.       
  372    The DNAME RDATA target name MUST NOT be sent out in compressed form     
  373    and MUST be downcased for DNS Security Extensions (DNSSEC)              
  374    validation.                                                             
  375                                                                            
  376                                                                            
  377                                                                            
  378                                                                            
  379                                                                            
  380                                                                            
  381                                                                            
  382 Rose & Wijngaards            Standards Track                    [Page 7]   

  383 RFC 6672                    DNAME Redirection                  June 2012   
  384                                                                            
  385                                                                            
  386    Although the previous DNAME specification [RFC2672] (that is            
  387    obsoleted by this specification) talked about signaling to allow        
  388    compression of the target name, such signaling has never been           
  389    specified, nor is it specified in this document.                        
  390                                                                            
  391    RFC 2672 (obsoleted by this document) states that the Extended DNS      
  392    (EDNS) version has a means for understanding DNAME and DNAME target     
  393    name compression.  This document revises RFC 2672, in that there is     
  394    no EDNS version signaling for DNAME.                                    
  395                                                                            
  396 3.  Processing                                                             
  397                                                                            
  398 3.1.  CNAME Synthesis                                                      
  399                                                                            
  400    When preparing a response, a server performing a DNAME substitution     
  401    will, in all cases, include the relevant DNAME RR in the answer         
  402    section.  Relevant cases includes the following:                        
  403                                                                            
  404    1.  The DNAME is being employed as a substitution instruction.          
  405                                                                            
  406    2.  The DNAME itself matches the QTYPE, and the owner name matches      
  407        QNAME.                                                              
  408                                                                            
  409    When the owner name matches the QNAME and the QTYPE matches another     
  410    type owned there, the DNAME is not included in the answer.              
  411                                                                            
  412    A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME     
  413    RR is synthesized and included in the answer section when the DNAME     
  414    is employed as a substitution instruction.  The owner name of the       
  415    CNAME is the QNAME of the query.  The DNSSEC specification ([RFC4033]   
  416    [RFC4034] [RFC4035]) says that the synthesized CNAME does not have to   
  417    be signed.  The signed DNAME has an RRSIG, and a validating resolver    
  418    can check the CNAME against the DNAME record and validate the           
  419    signature over the DNAME RR.                                            
  420                                                                            
  421    Servers MUST be able to answer a query for a synthesized CNAME.  Like   
  422    other query types, this invokes the DNAME, and then the server          
  423    synthesizes the CNAME and places it into the answer section.  If the    
  424    server in question is a cache, the synthesized CNAME's TTL SHOULD be    
  425    equal to the decremented TTL of the cached DNAME.                       
  426                                                                            
  427    Resolvers MUST be able to handle a synthesized CNAME TTL of zero or a   
  428    value equal to the TTL of the corresponding DNAME record (as some       
  429    older, authoritative server implementations set the TTL of              
  430    synthesized CNAMEs to zero).  A TTL of zero means that the CNAME can    
  431    be discarded immediately after processing the answer.                   
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Rose & Wijngaards            Standards Track                    [Page 8]   

  438 RFC 6672                    DNAME Redirection                  June 2012   
  439                                                                            
  440                                                                            
  441 3.2.  Server Algorithm                                                     
  442                                                                            
  443    Below is the revised version of the server algorithm, which appears     
  444    in RFC 2672, Section 4.1.                                               
  445                                                                            
  446    1.  Set or clear the value of recursion available in the response       
  447        depending on whether the name server is willing to provide          
  448        recursive service.  If recursive service is available and           
  449        requested via the RD bit in the query, go to step 5; otherwise,     
  450        step 2.                                                             
  451                                                                            
  452    2.  Search the available zones for the zone which is the nearest        
  453        ancestor to QNAME.  If such a zone is found, go to step 3;          
  454        otherwise, step 4.                                                  
  455                                                                            
  456    3.  Start matching down, label by label, in the zone.  The matching     
  457        process can terminate several ways:                                 
  458                                                                            
  459        A.  If the whole of QNAME is matched, we have found the node.       
  460                                                                            
  461            If the data at the node is a CNAME, and QTYPE does not match    
  462            CNAME, copy the CNAME RR into the answer section of the         
  463            response, change QNAME to the canonical name in the CNAME RR,   
  464            and go back to step 1.                                          
  465                                                                            
  466            Otherwise, copy all RRs which match QTYPE into the answer       
  467            section and go to step 6.                                       
  468                                                                            
  469        B.  If a match would take us out of the authoritative data, we      
  470            have a referral.  This happens when we encounter a node with    
  471            NS RRs marking cuts along the bottom of a zone.                 
  472                                                                            
  473            Copy the NS RRs for the sub-zone into the authority section     
  474            of the reply.  Put whatever addresses are available into the    
  475            additional section, using glue RRs if the addresses are not     
  476            available from authoritative data or the cache.  Go to step     
  477            4.                                                              
  478                                                                            
  479        C.  If at some label, a match is impossible (i.e., the              
  480            corresponding label does not exist), look to see whether the    
  481            last label matched has a DNAME record.                          
  482                                                                            
  483            If a DNAME record exists at that point, copy that record into   
  484            the answer section.  If substitution of its <target> for its    
  485            <owner> in QNAME would overflow the legal size for a <domain-   
  486            name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise,     
  487            perform the substitution and continue.  The server MUST         
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Rose & Wijngaards            Standards Track                    [Page 9]   

  493 RFC 6672                    DNAME Redirection                  June 2012   
  494                                                                            
  495                                                                            
  496            synthesize a CNAME record as described above and include it     
  497            in the answer section.  Go back to step 1.                      
  498                                                                            
  499            If there was no DNAME record, look to see if the "*" label      
  500            exists.                                                         
  501                                                                            
  502            If the "*" label does not exist, check whether the name we      
  503            are looking for is the original QNAME in the query or a name    
  504            we have followed due to a CNAME or DNAME.  If the name is       
  505            original, set an authoritative name error in the response and   
  506            exit.  Otherwise, just exit.                                    
  507                                                                            
  508            If the "*" label does exist, match RRs at that node against     
  509            QTYPE.  If any match, copy them into the answer section, but    
  510            set the owner of the RR to be QNAME, and not the node with      
  511            the "*" label.  If the data at the node with the "*" label is   
  512            a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR       
  513            into the answer section of the response changing the owner      
  514            name to the QNAME, change QNAME to the canonical name in the    
  515            CNAME RR, and go back to step 1.  Otherwise, go to step 6.      
  516                                                                            
  517    4.  Start matching down in the cache.  If QNAME is found in the         
  518        cache, copy all RRs attached to it that match QTYPE into the        
  519        answer section.  If QNAME is not found in the cache but a DNAME     
  520        record is present at an ancestor of QNAME, copy that DNAME record   
  521        into the answer section.  If there was no delegation from           
  522        authoritative data, look for the best one from the cache, and put   
  523        it in the authority section.  Go to step 6.                         
  524                                                                            
  525    5.  Use the local resolver or a copy of its algorithm to answer the     
  526        query.  Store the results, including any intermediate CNAMEs and    
  527        DNAMEs, in the answer section of the response.                      
  528                                                                            
  529    6.  Using local data only, attempt to add other RRs that may be         
  530        useful to the additional section of the query.  Exit.               
  531                                                                            
  532    Note that there will be at most one ancestor with a DNAME as            
  533    described in step 4 unless some zone's data is in violation of the      
  534    no-descendants limitation in Section 3.  An implementation might take   
  535    advantage of this limitation by stopping the search of step 3c or       
  536    step 4 when a DNAME record is encountered.                              
  537                                                                            
  538 3.3.  Wildcards                                                            
  539                                                                            
  540    The use of DNAME in conjunction with wildcards is discouraged           
  541    [RFC4592].  Thus, records of the form "*.example.com DNAME              
  542    example.net" SHOULD NOT be used.                                        
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Rose & Wijngaards            Standards Track                   [Page 10]   

  548 RFC 6672                    DNAME Redirection                  June 2012   
  549                                                                            
  550                                                                            
  551    The interaction between the expansion of the wildcard and the           
  552    redirection of the DNAME is non-deterministic.  Due to the fact that    
  553    the processing is non-deterministic, DNSSEC validating resolvers may    
  554    not be able to validate a wildcarded DNAME.                             
  555                                                                            
  556    A server MAY give a warning that the behavior is unspecified if such    
  557    a wildcarded DNAME is loaded.  The server MAY refuse it, refuse to      
  558    load the zone, or refuse dynamic updates.                               
  559                                                                            
  560 3.4.  Acceptance and Intermediate Storage                                  
  561                                                                            
  562    Recursive caching name servers can encounter data at names below the    
  563    owner name of a DNAME RR, due to a change at the authoritative server   
  564    where data from before and after the change resides in the cache.       
  565    This conflict situation is a transitional phase that ends when the      
  566    old data times out.  The caching name server can opt to store both      
  567    old and new data and treat each as if the other did not exist, or       
  568    drop the old data, or drop the longer domain name.  In any approach,    
  569    consistency returns after the older data TTL times out.                 
  570                                                                            
  571    Recursive caching name servers MUST perform CNAME synthesis on behalf   
  572    of clients.                                                             
  573                                                                            
  574    If a recursive caching name server encounters a DNSSEC validated        
  575    DNAME RR that contradicts information already in the cache (excluding   
  576    CNAME records), it SHOULD cache the DNAME RR, but it MAY cache the      
  577    CNAME record received along with it, subject to the rules for CNAME.    
  578    If the DNAME RR cannot be validated via DNSSEC (i.e., not BOGUS, but    
  579    not able to validate), the recursive caching server SHOULD NOT cache    
  580    the DNAME RR but MAY cache the CNAME record received along with it,     
  581    subject to the rules for CNAME.                                         
  582                                                                            
  583 3.4.1.  Resolver Algorithm                                                 
  584                                                                            
  585    Below is the revised version of the resolver algorithm, which appears   
  586    in RFC 2672, Section 4.2.                                               
  587                                                                            
  588    1.  See if the answer is in local information or can be synthesized     
  589        from a cached DNAME; if so, return it to the client.                
  590                                                                            
  591    2.  Find the best servers to ask.                                       
  592                                                                            
  593    3.  Send queries until one returns a response.                          
  594                                                                            
  595                                                                            
  596                                                                            
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Rose & Wijngaards            Standards Track                   [Page 11]   

  603 RFC 6672                    DNAME Redirection                  June 2012   
  604                                                                            
  605                                                                            
  606    4.  Analyze the response, either:                                       
  607                                                                            
  608        A.  If the response answers the question or contains a name         
  609            error, cache the data as well as return it back to the          
  610            client.                                                         
  611                                                                            
  612        B.  If the response contains a better delegation to other           
  613            servers, cache the delegation information, and go to step 2.    
  614                                                                            
  615        C.  If the response shows a CNAME and that is not the answer        
  616            itself, cache the CNAME, change the SNAME to the canonical      
  617            name in the CNAME RR, and go to step 1.                         
  618                                                                            
  619        D.  If the response shows a DNAME and that is not the answer        
  620            itself, cache the DNAME (upon successful DNSSEC validation if   
  621            the client is a validating resolver).  If substitution of the   
  622            DNAME's target name for its owner name in the SNAME would       
  623            overflow the legal size for a domain name, return an            
  624            implementation-dependent error to the application; otherwise,   
  625            perform the substitution and go to step 1.                      
  626                                                                            
  627        E.  If the response shows a server failure or other bizarre         
  628            contents, delete the server from the SLIST and go back to       
  629            step 3.                                                         
  630                                                                            
  631 4.  DNAME Discussions in Other Documents                                   
  632                                                                            
  633    In Section 10.3 of [RFC2181], the discussion on MX and NS records       
  634    touches on redirection by CNAMEs, but this also holds for DNAMEs.       
  635                                                                            
  636    Section 10.3 ("MX and NS records") of [RFC2181] states:                 
  637                                                                            
  638            The domain name used as the value of a NS resource record,      
  639            or part of the value of a MX resource record must not be        
  640            an alias.  Not only is the specification clear on this          
  641            point, but using an alias in either of these positions          
  642            neither works as well as might be hoped, nor well fulfills      
  643            the ambition that may have led to this approach.  This          
  644            domain name must have as its value one or more address          
  645            records.  Currently those will be A records, however in         
  646            the future other record types giving addressing                 
  647            information may be acceptable.  It can also have other          
  648            RRs, but never a CNAME RR.                                      
  649                                                                            
  650    The DNAME RR is discussed in RFC 3363, Section 4, on A6 and DNAME.      
  651    The opening premise of this section is demonstrably wrong, and so the   
  652    conclusion based on that premise is wrong.  In particular, [RFC3363]    
  653    deprecates the use of DNAME in the IPv6 reverse tree.  Based on the     
  654                                                                            
  655                                                                            
  656                                                                            
  657 Rose & Wijngaards            Standards Track                   [Page 12]   

  658 RFC 6672                    DNAME Redirection                  June 2012   
  659                                                                            
  660                                                                            
  661    experience gained in the meantime, [RFC3363] is revised, dropping all   
  662    constraints on having DNAME RRs in these zones [RFC6434].  This would   
  663    greatly improve the manageability of the IPv6 reverse tree.  These      
  664    changes are made explicit below.                                        
  665                                                                            
  666    In [RFC3363], the following paragraph is updated by this document,      
  667    and the use of DNAME RRs in the reverse tree is no longer deprecated.   
  668                                                                            
  669      The issues for DNAME in the reverse mapping tree appears to be        
  670      closely tied to the need to use fragmented A6 in the main tree: if    
  671      one is necessary, so is the other, and if one isn't necessary, the    
  672      other isn't either.  Therefore, in moving RFC 2874 to experimental,   
  673      the intent of this document is that use of DNAME RRs in the reverse   
  674      tree be deprecated.                                                   
  675                                                                            
  676 5.  Other Issues with DNAME                                                
  677                                                                            
  678    There are several issues to be aware of about the use of DNAME.         
  679                                                                            
  680 5.1.  Canonical Hostnames Cannot Be below DNAME Owners                     
  681                                                                            
  682    The names listed as target names of MX, NS, PTR, and SRV [RFC2782]      
  683    records must be canonical hostnames.  This means no CNAME or DNAME      
  684    redirection may be present during DNS lookup of the address records     
  685    for the host.  This is discussed in RFC 2181 [RFC2181], Section 10.3,   
  686    and RFC 1912 [RFC1912], Section 2.4.  For SRV, see RFC 2782             
  687    [RFC2782], page 4.                                                      
  688                                                                            
  689    The upshot of this is that although the lookup of a PTR record can      
  690    involve DNAMEs, the name listed in the PTR record cannot fall under a   
  691    DNAME.  The same holds for NS, SRV, and MX records.  For example,       
  692    when punycode [RFC3492] alternates for a zone use DNAME, then the NS,   
  693    MX, SRV, and PTR records that point to that zone must use names that    
  694    are not aliases in their RDATA.  Then, what must be done is to have     
  695    the domain names with DNAME substitution already applied to it as the   
  696    MX, NS, PTR, and SRV data.  These are valid canonical hostnames.        
  697                                                                            
  698 5.2.  Dynamic Update and DNAME                                             
  699                                                                            
  700    DNAME records can be added, changed, and removed in a zone using        
  701    dynamic update transactions.  Adding a DNAME RR to a zone occludes      
  702    any domain names that may exist under the added DNAME.                  
  703                                                                            
  704    If a dynamic update message attempts to add a DNAME with a given        
  705    owner name, but a CNAME is associated with that name, then the server   
  706    MUST ignore the DNAME.  If a DNAME is already associated with that      
  707    name, then it is replaced with the new DNAME.  Otherwise, add the       
  708    DNAME.  If a CNAME is added with a given owner name, but a DNAME is     
  709                                                                            
  710                                                                            
  711                                                                            
  712 Rose & Wijngaards            Standards Track                   [Page 13]   

  713 RFC 6672                    DNAME Redirection                  June 2012   
  714                                                                            
  715                                                                            
  716    associated with that name, then the CNAME MUST be ignored.  Similar     
  717    behavior occurs for dynamic updates to an owner name of a CNAME RR      
  718    [RFC2136].                                                              
  719                                                                            
  720 5.3.  DNSSEC and DNAME                                                     
  721                                                                            
  722    The following subsections specify the behavior of implementations       
  723    that understand both DNSSEC and DNAME (synthesis).                      
  724                                                                            
  725 5.3.1.  Signed DNAME, Unsigned Synthesized CNAME                           
  726                                                                            
  727    In any response, a signed DNAME RR indicates a non-terminal             
  728    redirection of the query.  There might or might not be a server-        
  729    synthesized CNAME in the answer section; if there is, the CNAME will    
  730    never be signed.  For a DNSSEC validator, verification of the DNAME     
  731    RR and then that the CNAME was properly synthesized is sufficient       
  732    proof.                                                                  
  733                                                                            
  734 5.3.2.  DNAME Bit in NSEC Type Map                                         
  735                                                                            
  736    In any negative response, the NSEC or NSEC3 [RFC5155] record type       
  737    bitmap SHOULD be checked to see that there was no DNAME that could      
  738    have been applied.  If the DNAME bit in the type bitmap is set and      
  739    the query name is a subdomain of the closest encloser that is           
  740    asserted, then DNAME substitution should have been done, but the        
  741    substitution has not been done as specified.                            
  742                                                                            
  743 5.3.3.  DNAME Chains as Strong as the Weakest Link                         
  744                                                                            
  745    A response can contain a chain of DNAME and CNAME redirections.  That   
  746    chain can end in a positive answer or a negative reply (no name error   
  747    or no data error).  Each step in that chain results in resource         
  748    records being added to the answer or authority section of the           
  749    response.  Only if all steps are secure can the AD (Authentic Data)     
  750    bit be set for the response.  If one of the steps is bogus, the         
  751    result is bogus.                                                        
  752                                                                            
  753 5.3.4.  Validators Must Understand DNAME                                   
  754                                                                            
  755    Below are examples of why DNSSEC validators MUST understand DNAME.      
  756    In the examples, SOA records, wildcard denial NSECs, and other          
  757    material not under discussion have been omitted or shortened.           
  758                                                                            
  759                                                                            
  760                                                                            
  761                                                                            
  762                                                                            
  763                                                                            
  764                                                                            
  765                                                                            
  766                                                                            
  767 Rose & Wijngaards            Standards Track                   [Page 14]   

  768 RFC 6672                    DNAME Redirection                  June 2012   
  769                                                                            
  770                                                                            

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 V. Risk, ISC.orgBIND 9 implementation note2022-08-15

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

  771 5.3.4.1.  Invalid Name Error Response Caused by DNAME in Bitmap            
  772                                                                            
  773    ;; Header: QR AA RCODE=3(NXDOMAIN)                                      
  774    ;; OPT PSEUDOSECTION:                                                   
  775    ; EDNS: version: 0, flags: do; udp: 4096                                
  776                                                                            
  777    ;; Question                                                             
  778    foo.bar.example.com. IN A                                               
  779    ;; Authority                                                            
  780    bar.example.com. NSEC dub.example.com. A DNAME                          
  781    bar.example.com. RRSIG NSEC [valid signature]                           
  782                                                                            
  783    If this is the received response, then only by understanding that the   
  784    DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to   
  785    have been redirected by the DNAME, the validator can see that it is a   
  786    BOGUS reply from an attacker that collated existing records from the    
  787    DNS to create a confusing reply.                                        
  788                                                                            
  789    If the DNAME bit had not been set in the NSEC record above, then the    
  790    answer would have validated as a correct name error response.           
  791                                                                            
section-5.3.4.1 Pieter Lexis(Editorial Erratum #5297) [Verified]
based on outdated version
   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME 
   bar.example.com. RRSIG NSEC [valid signature]
It should say:
   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   foo.bar.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [valid signature]

The NSEC record in the original text would in no case be valid as it denies it's own existence and the existence of the RRSIG, while the text indicates that " the validator can see that it is a BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply". This indicates that NSEC and RRSIG should be set in the NSEC bitmap.

Edit: Thread: https://www.ietf.org/mail-archive/web/dnsext/current/msg13879.html
  792 5.3.4.2.  Valid Name Error Response Involving DNAME in Bitmap              
  793                                                                            
  794    ;; Header: QR AA RCODE=3(NXDOMAIN)                                      
  795    ;; OPT PSEUDOSECTION:                                                   
  796    ; EDNS: version: 0, flags: do; udp: 4096                                
  797                                                                            
  798    ;; Question                                                             
  799    cee.example.com. IN A                                                   
  800    ;; Authority                                                            
  801    bar.example.com. NSEC dub.example.com. A DNAME                          
  802    bar.example.com. RRSIG NSEC [valid signature]                           
  803                                                                            
  804    This response has the same NSEC records as the example above, but       
  805    with this query name (cee.example.com), the answer is validated,        
  806    because 'cee' does not get redirected by the DNAME at 'bar'.            
  807                                                                            
  808                                                                            
  809                                                                            
  810                                                                            
  811                                                                            
  812                                                                            
  813                                                                            
  814                                                                            
  815                                                                            
  816                                                                            
  817                                                                            
  818                                                                            
  819                                                                            
  820                                                                            
  821                                                                            
  822 Rose & Wijngaards            Standards Track                   [Page 15]   

  823 RFC 6672                    DNAME Redirection                  June 2012   
  824                                                                            
  825                                                                            
  826 5.3.4.3.  Response with Synthesized CNAME                                  
  827                                                                            
  828    ;; Header: QR AA RCODE=0(NOERROR)                                       
  829    ;; OPT PSEUDOSECTION:                                                   
  830    ; EDNS: version: 0, flags: do; udp: 4096                                
  831                                                                            
  832    ;; Question                                                             
  833    foo.bar.example.com. IN A                                               
  834    ;; Answer                                                               
  835    bar.example.com. DNAME bar.example.net.                                 
  836    bar.example.com. RRSIG DNAME [valid signature]                          
  837    foo.bar.example.com. CNAME foo.bar.example.net.                         
  838                                                                            
  839    The response shown above has the synthesized CNAME included.            
  840    However, the CNAME has no signature, since the server does not sign     
  841    online.  So this response cannot be trusted.  It could be altered by    
  842    an attacker to be foo.bar.example.com CNAME bla.bla.example.  The       
  843    DNAME record does have its signature included, since it does not        
  844    change.  The validator must verify the DNAME signature and then         
  845    recursively resolve further in order to query for the                   
  846    foo.bar.example.net A record.                                           
  847                                                                            
  848 6.  Examples of DNAME Use in a Zone                                        
  849                                                                            
  850    Below are some examples of the use of DNAME in a zone.  These           
  851    examples are by no means exhaustive.                                    
  852                                                                            
  853 6.1.  Organizational Renaming                                              
  854                                                                            
  855    If an organization with domain name FROBOZZ.EXAMPLE.NET became part     
  856    of an organization with domain name ACME.EXAMPLE.COM, it might ease     
  857    transition by placing information such as this in its old zone.         
  858                                                                            
  859        frobozz.example.net.  DNAME    frobozz-division.acme.example.com.   
  860                              MX       10       mailhub.acme.example.com.   
  861                                                                            
  862    The response to an extended recursive query for                         
  863    www.frobozz.example.net would contain, in the answer section, the       
  864    DNAME record shown above and the relevant RRs for www.frobozz-          
  865    division.acme.example.com.                                              
  866                                                                            
  867    If an organization wants to have aliases for names, for a different     
  868    spelling or language, the same example applies.  Note that the MX RR    
  869    at the zone apex is not redirected and has to be repeated in the        
  870    target zone.  Also note that the services at mailhub or www.frobozz-    
  871    division.acme.example.com. have to recognize and handle the aliases.    
  872                                                                            
  873                                                                            
  874                                                                            
  875                                                                            
  876                                                                            
  877 Rose & Wijngaards            Standards Track                   [Page 16]   

  878 RFC 6672                    DNAME Redirection                  June 2012   
  879                                                                            
  880                                                                            
  881 6.2.  Classless Delegation of Shorter Prefixes                             
  882                                                                            
  883    The classless scheme for in-addr.arpa delegation [RFC2317] can be       
  884    extended to prefixes shorter than 24 bits by use of the DNAME record.   
  885    For example, the prefix 192.0.8.0/22 can be delegated by the            
  886    following records.                                                      
  887                                                                            
  888        $ORIGIN 0.192.in-addr.arpa.                                         
  889        8/22    NS       ns.slash-22-holder.example.com.                    
  890        8       DNAME    8.8/22                                             
  891        9       DNAME    9.8/22                                             
  892        10      DNAME    10.8/22                                            
  893        11      DNAME    11.8/22                                            
  894                                                                            
  895    A typical entry in the resulting reverse zone for some host with        
  896    address 192.0.9.33 might be as follows:                                 
  897                                                                            
  898         $ORIGIN 8/22.0.192.in-addr.arpa.                                   
  899         33.9    PTR     somehost.slash-22-holder.example.com.              
  900                                                                            
  901    The advisory remarks in [RFC2317] concerning the choice of the "/"      
  902    character apply here as well.                                           
  903                                                                            
  904 6.3.  Network Renumbering Support                                          
  905                                                                            
  906    If IPv4 network renumbering were common, maintenance of address space   
  907    delegation could be simplified by using DNAME records instead of NS     
  908    records to delegate.                                                    
  909                                                                            
  910        $ORIGIN new-style.in-addr.arpa.                                     
  911        189.190           DNAME    in-addr.example.net.                     
  912                                                                            
  913        $ORIGIN in-addr.example.net.                                        
  914        188               DNAME    in-addr.customer.example.com.            
  915                                                                            
  916        $ORIGIN in-addr.customer.example.                                   
  917        1                 PTR      www.customer.example.com                 
  918        2                 PTR      mailhub.customer.example.com.            
  919        ; etc ...                                                           
  920                                                                            
  921    This would allow the address space 190.189.0.0/16 assigned to the ISP   
  922    "example.net" to be changed without having to alter the zone data       
  923    describing the use of that space by the ISP and its customers.          
  924                                                                            
  925                                                                            
  926                                                                            
  927                                                                            
  928                                                                            
  929                                                                            
  930                                                                            
  931                                                                            
  932 Rose & Wijngaards            Standards Track                   [Page 17]   

  933 RFC 6672                    DNAME Redirection                  June 2012   
  934                                                                            
  935                                                                            
  936    Renumbering IPv4 networks is currently so arduous a task that           
  937    updating the DNS is only a small part of the labor, so this scheme      
  938    may have a low value.  But it is hoped that in IPv6 the renumbering     
  939    task will be quite different, and the DNAME mechanism may play a        
  940    useful part.                                                            
  941                                                                            
  942 7.  IANA Considerations                                                    
  943                                                                            
  944    The DNAME resource record type code 39 (decimal) originally was         
  945    registered by [RFC2672] in the DNS Resource Record (RR) Types           
  946    registry table at http://www.iana.org/assignments/dns-parameters.       
  947    IANA has updated the DNS resource record registry to point to this      
  948    document for RR type 39.                                                
  949                                                                            
  950 8.  Security Considerations                                                
  951                                                                            
  952    DNAME redirects queries elsewhere, which may impact security based on   
  953    policy and the security status of the zone with the DNAME and the       
  954    redirection zone's security status.  For validating resolvers, the      
  955    lowest security status of the links in the chain of CNAME and DNAME     
  956    redirections is applied to the result.                                  
  957                                                                            
  958    If a validating resolver accepts wildcarded DNAMEs, this creates        
  959    security issues.  Since the processing of a wildcarded DNAME is non-    
  960    deterministic and the CNAME that was substituted by the server has no   
  961    signature, the resolver may choose a different result than what the     
  962    server meant, and consequently end up at the wrong destination.  Use    
  963    of wildcarded DNAMEs is discouraged in any case [RFC4592].              
  964                                                                            
  965    A validating resolver MUST understand DNAME, according to [RFC4034].    
  966    The examples in Section 5.3.4 illustrate this need.                     
  967                                                                            
  968 9.  Acknowledgments                                                        
  969                                                                            
  970    The authors of this document would like to acknowledge Matt Larson      
  971    for beginning this effort to address the issues related to the DNAME    
  972    RR type.  The authors would also like to acknowledge Paul Vixie, Ed     
  973    Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred   
  974    Hoenes, and Kevin Darcy for their reviews and comments on this          
  975    document.                                                               
  976                                                                            
  977                                                                            
  978                                                                            
  979                                                                            
  980                                                                            
  981                                                                            
  982                                                                            
  983                                                                            
  984                                                                            
  985                                                                            
  986                                                                            
  987 Rose & Wijngaards            Standards Track                   [Page 18]   

  988 RFC 6672                    DNAME Redirection                  June 2012   
  989                                                                            
  990                                                                            
  991 10.  References                                                            
  992                                                                            
  993 10.1.  Normative References                                                
  994                                                                            
  995    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  996               STD 13, RFC 1034, November 1987.                             
  997                                                                            
  998    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  999               specification", STD 13, RFC 1035, November 1987.             
 1000                                                                            
 1001    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1002               Requirement Levels", BCP 14, RFC 2119, March 1997.           
 1003                                                                            
 1004    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,           
 1005               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
 1006               RFC 2136, April 1997.                                        
 1007                                                                            
 1008    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
 1009               Specification", RFC 2181, July 1997.                         
 1010                                                                            
 1011    [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-       
 1012               ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.         
 1013                                                                            
 1014    [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for     
 1015               specifying the location of services (DNS SRV)", RFC 2782,    
 1016               February 2000.                                               
 1017                                                                            
 1018    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record     
 1019               (RR) Types", RFC 3597, September 2003.                       
 1020                                                                            
 1021    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1022               Rose, "DNS Security Introduction and Requirements",          
 1023               RFC 4033, March 2005.                                        
 1024                                                                            
 1025    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1026               Rose, "Resource Records for the DNS Security Extensions",    
 1027               RFC 4034, March 2005.                                        
 1028                                                                            
 1029    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1030               Rose, "Protocol Modifications for the DNS Security           
 1031               Extensions", RFC 4035, March 2005.                           
 1032                                                                            
 1033    [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name         
 1034               System", RFC 4592, July 2006.                                
 1035                                                                            
 1036    [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS      
 1037               Security (DNSSEC) Hashed Authenticated Denial of             
 1038               Existence", RFC 5155, March 2008.                            
 1039                                                                            
 1040                                                                            
 1041                                                                            
 1042 Rose & Wijngaards            Standards Track                   [Page 19]   

 1043 RFC 6672                    DNAME Redirection                  June 2012   
 1044                                                                            
 1045                                                                            
 1046 10.2.  Informative References                                              
 1047                                                                            
 1048    [RFC1912]  Barr, D., "Common DNS Operational and Configuration          
 1049               Errors", RFC 1912, February 1996.                            
 1050                                                                            
 1051    [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection",           
 1052               RFC 2672, August 1999.                                       
 1053                                                                            
 1054    [RFC3363]  Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.      
 1055               Hain, "Representing Internet Protocol version 6 (IPv6)       
 1056               Addresses in the Domain Name System (DNS)", RFC 3363,        
 1057               August 2002.                                                 
 1058                                                                            
 1059    [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode    
 1060               for Internationalized Domain Names in Applications           
 1061               (IDNA)", RFC 3492, March 2003.                               
 1062                                                                            
 1063    [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node      
 1064               Requirements", RFC 6434, December 2011.                      
 1065                                                                            
 1066                                                                            
 1067                                                                            
 1068                                                                            
 1069                                                                            
 1070                                                                            
 1071                                                                            
 1072                                                                            
 1073                                                                            
 1074                                                                            
 1075                                                                            
 1076                                                                            
 1077                                                                            
 1078                                                                            
 1079                                                                            
 1080                                                                            
 1081                                                                            
 1082                                                                            
 1083                                                                            
 1084                                                                            
 1085                                                                            
 1086                                                                            
 1087                                                                            
 1088                                                                            
 1089                                                                            
 1090                                                                            
 1091                                                                            
 1092                                                                            
 1093                                                                            
 1094                                                                            
 1095                                                                            
 1096                                                                            
 1097 Rose & Wijngaards            Standards Track                   [Page 20]   

 1098 RFC 6672                    DNAME Redirection                  June 2012   
 1099                                                                            
 1100                                                                            
 1101 Appendix A.  Changes from RFC 2672                                         
 1102                                                                            
 1103 A.1.  Changes to Server Behavior                                           
 1104                                                                            
 1105    Major changes to server behavior from the original DNAME                
 1106    specification are summarized below:                                     
 1107                                                                            
 1108    o  The rules for DNAME substitution have been clarified in              
 1109       Section 2.2.                                                         
 1110                                                                            
 1111    o  The EDNS option to signal DNAME understanding and compression has    
 1112       never been specified, and this document clarifies that there is no   
 1113       signaling method (Section 2.5).                                      
 1114                                                                            
 1115    o  The TTL for synthesized CNAME RRs is now set to the TTL of the       
 1116       DNAME, not zero (Section 3.1).                                       
 1117                                                                            
 1118    o  Recursive caching servers MUST perform CNAME synthesis on behalf     
 1119       of clients (Section 3.4).                                            
 1120                                                                            
 1121    o  The revised server algorithm is detailed in Section 3.2.             
 1122                                                                            
 1123    o  Rules for dynamic update messages adding a DNAME or CNAME RR to a    
 1124       zone where a CNAME or DNAME already exists are detailed in           
 1125       Section 5.2.                                                         
 1126                                                                            
 1127 A.2.  Changes to Client Behavior                                           
 1128                                                                            
 1129    Major changes to client behavior from the original DNAME                
 1130    specification are summarized below:                                     
 1131                                                                            
 1132    o  Clients MUST be able to accept synthesized CNAME RR's with a TTL     
 1133       of either zero or the TTL of the DNAME RR that accompanies the       
 1134       CNAME RR.                                                            
 1135                                                                            
 1136    o  DNSSEC-aware clients SHOULD cache DNAME RRs and MAY cache            
 1137       synthesized CNAME RRs they receive in the same response.  DNSSEC-    
 1138       aware clients SHOULD also check the NSEC/NSEC3 type bitmap to        
 1139       verify that DNAME redirection is to be done.  DNSSEC validators      
 1140       MUST understand DNAME (Section 5.3).                                 
 1141                                                                            
 1142    o  The revised client algorithm is detailed in Section 3.4.1.           
 1143                                                                            
 1144                                                                            
 1145                                                                            
 1146                                                                            
 1147                                                                            
 1148                                                                            
 1149                                                                            
 1150                                                                            
 1151                                                                            
 1152 Rose & Wijngaards            Standards Track                   [Page 21]   

 1153 RFC 6672                    DNAME Redirection                  June 2012   
 1154                                                                            
 1155                                                                            
 1156 Authors' Addresses                                                         
 1157                                                                            
 1158    Scott Rose                                                              
 1159    NIST                                                                    
 1160    100 Bureau Dr.                                                          
 1161    Gaithersburg, MD  20899                                                 
 1162    USA                                                                     
 1163                                                                            
 1164    Phone: +1-301-975-8439                                                  
 1165    Fax:   +1-301-975-6238                                                  
 1166    EMail: scott.rose@nist.gov                                              
 1167                                                                            
 1168                                                                            
 1169    Wouter Wijngaards                                                       
 1170    NLnet Labs                                                              
 1171    Science Park 140                                                        
 1172    Amsterdam  1098 XH                                                      
 1173    The Netherlands                                                         
 1174                                                                            
 1175    Phone: +31-20-888-4551                                                  
 1176    EMail: wouter@nlnetlabs.nl                                              
 1177                                                                            
 1178                                                                            
 1179                                                                            
 1180                                                                            
 1181                                                                            
 1182                                                                            
 1183                                                                            
 1184                                                                            
 1185                                                                            
 1186                                                                            
 1187                                                                            
 1188                                                                            
 1189                                                                            
 1190                                                                            
 1191                                                                            
 1192                                                                            
 1193                                                                            
 1194                                                                            
 1195                                                                            
 1196                                                                            
 1197                                                                            
 1198                                                                            
 1199                                                                            
 1200                                                                            
 1201                                                                            
 1202                                                                            
 1203                                                                            
 1204                                                                            
 1205                                                                            
 1206                                                                            
 1207 Rose & Wijngaards            Standards Track                   [Page 22]   
 1208                                                                            
section-5.3.4.2 Pieter Lexis(Editorial Erratum #5298) [Reported]
based on outdated version
   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   cee.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME
   bar.example.com. RRSIG NSEC [valid signature]
It should say:
   ;; Header: QR AA RCODE=3(NXDOMAIN)
   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags: do; udp: 4096

   ;; Question
   cee.example.com. IN A
   ;; Authority
   bar.example.com. NSEC dub.example.com. A DNAME RRSIG NSEC
   bar.example.com. RRSIG NSEC [valid signature]

The NSEC record in the original text would in no case be valid as it denies it's own existence and the existence of the RRSIG, while the text indicates that " the validator can see that it is a BOGUS reply from an attacker that collated existing records from the DNS to create a confusing reply". This indicates that NSEC and RRSIG should be set in the NSEC bitmap

Edit: Thread - https://www.ietf.org/mail-archive/web/dnsext/current/msg13879.html