1 Network Working Group                                          R. Arends   
    2 Request for Comments: 4035                          Telematica Instituut   
    3 Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein   
    4            3755, 3757, 3845                                          ISC   

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).

GLOBAL P. Hoffman, ICANNUpdates from RFC 6840

RFC6840, "Clarifications and Implementation Notes for DNSSEC", updates RFC 4035 in many places throughout the document.

RFC6014 says that it updates RFC 4035, and talks about RFC 4035 in a few places, but doesn't seem to update any of the material in RFC 4035.

    5 Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson   
    6          3007, 3597, 3226                                       VeriSign   
    7 Category: Standards Track                                      D. Massey   
    8                                                Colorado State University   
    9                                                                  S. Rose   
   10                                                                     NIST   
   11                                                               March 2005   
   12                                                                            
   13                                                                            
   14          Protocol Modifications for the DNS Security Extensions            
   15                                                                            
   16 Status of This Memo                                                        
   17                                                                            
   18    This document specifies an Internet standards track protocol for the    
   19    Internet community, and requests discussion and suggestions for         
   20    improvements.  Please refer to the current edition of the "Internet     
   21    Official Protocol Standards" (STD 1) for the standardization state      
   22    and status of this protocol.  Distribution of this memo is unlimited.   
   23                                                                            
   24 Copyright Notice                                                           
   25                                                                            
   26    Copyright (C) The Internet Society (2005).                              
   27                                                                            
   28 Abstract                                                                   
   29                                                                            
   30    This document is part of a family of documents that describe the DNS    
   31    Security Extensions (DNSSEC).  The DNS Security Extensions are a        
   32    collection of new resource records and protocol modifications that      
   33    add data origin authentication and data integrity to the DNS.  This     
   34    document describes the DNSSEC protocol modifications.  This document    
   35    defines the concept of a signed zone, along with the requirements for   
   36    serving and resolving by using DNSSEC.  These techniques allow a        
   37    security-aware resolver to authenticate both DNS resource records and   
   38    authoritative DNS error indications.                                    
   39                                                                            
   40    This document obsoletes RFC 2535 and incorporates changes from all      
   41    updates to RFC 2535.                                                    
   42                                                                            
   43                                                                            
   44                                                                            
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Arends, et al.              Standards Track                     [Page 1]   

   53 RFC 4035             DNSSEC Protocol Modifications            March 2005   
   54                                                                            
   55                                                                            
   56 Table of Contents                                                          
   57                                                                            
   58    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3   
   59        1.1.  Background and Related Documents . . . . . . . . . . . .  4   
   60        1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4   
   61    2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4   
   62        2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5   
   63        2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5   
   64        2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6   
   65        2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7   
   66        2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7   
   67        2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8   
   68        2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8   
   69    3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8   
   70        3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9   
   71              3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10   
   72              3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11   
   73              3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11   
   74              3.1.4.  Including DS RRs in a Response . . . . . . . . . 14   
   75              3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15   
   76              3.1.6.  The AD and CD Bits in an Authoritative Response. 16   
   77        3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17   
   78              3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17   
   79              3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17   
   80              3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18   
   81        3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19   
   82    4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19   
   83        4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19   
   84        4.2.  Signature Verification Support . . . . . . . . . . . . . 19   
   85        4.3.  Determining Security Status of Data  . . . . . . . . . . 20   
   86        4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21   
   87        4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21   
   88        4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22   
   89        4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22   
   90        4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23   
   91        4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23   
   92              4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24   
   93              4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24   
   94              4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24   
   95    5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25   
   96        5.1.  Special Considerations for Islands of Security . . . . . 26   
   97        5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26   
   98        5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28   
   99              5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28   
  100              5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29   
  101              5.3.3.  Checking the Signature . . . . . . . . . . . . . 31   
  102              5.3.4.  Authenticating a Wildcard Expanded RRset              
  103                      Positive Response. . . . . . . . . . . . . . . . 32   
  104                                                                            
  105                                                                            
  106                                                                            
  107 Arends, et al.              Standards Track                     [Page 2]   

  108 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  109                                                                            
  110                                                                            
  111        5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32   
  112        5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33   
  113        5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33   
  114    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33   
  115    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33   
  116    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34   
  117    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34   
  118        9.1.  Normative References . . . . . . . . . . . . . . . . . . 34   
  119        9.2.  Informative References . . . . . . . . . . . . . . . . . 35   
  120    A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36   
  121    B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41   
  122        B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41   
  123        B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43   
  124        B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44   
  125        B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44   
  126        B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45   
  127        B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46   
  128        B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47   
  129        B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48   
  130    C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49   
  131        C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49   
  132              C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49   
  133        C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50   
  134        C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50   
  135        C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50   
  136        C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51   
  137        C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51   
  138        C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51   
  139        C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51   
  140    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52   
  141    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53   
  142                                                                            
  143 1.  Introduction                                                           
  144                                                                            
  145    The DNS Security Extensions (DNSSEC) are a collection of new resource   
  146    records and protocol modifications that add data origin                 
  147    authentication and data integrity to the DNS.  This document defines    
  148    the DNSSEC protocol modifications.  Section 2 of this document          
  149    defines the concept of a signed zone and lists the requirements for     
  150    zone signing.  Section 3 describes the modifications to authoritative   
  151    name server behavior necessary for handling signed zones.  Section 4    
  152    describes the behavior of entities that include security-aware          
  153    resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs   
  154    to authenticate a response.                                             
  155                                                                            
  156                                                                            
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Arends, et al.              Standards Track                     [Page 3]   

  163 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  164                                                                            
  165                                                                            
  166 1.1.  Background and Related Documents                                     
  167                                                                            
  168    This document is part of a family of documents defining DNSSEC that     
  169    should be read together as a set.                                       
  170                                                                            
  171    [RFC4033] contains an introduction to DNSSEC and definitions of         
  172    common terms; the reader is assumed to be familiar with this            
  173    document.  [RFC4033] also contains a list of other documents updated    
  174    by and obsoleted by this document set.                                  
  175                                                                            
  176    [RFC4034] defines the DNSSEC resource records.                          
  177                                                                            
  178    The reader is also assumed to be familiar with the basic DNS concepts   
  179    described in [RFC1034], [RFC1035], and the subsequent documents that    
  180    update them; particularly, [RFC2181] and [RFC2308].                     
  181                                                                            
  182    This document defines the DNSSEC protocol operations.                   
  183                                                                            
  184 1.2.  Reserved Words                                                       
  185                                                                            
  186    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  187    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this    
  188    document are to be interpreted as described in [RFC2119].               
  189                                                                            
  190 2.  Zone Signing                                                           
  191                                                                            
  192    DNSSEC introduces the concept of signed zones.  A signed zone           
  193    includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),    
  194    Next Secure (NSEC), and (optionally) Delegation Signer (DS) records     
  195    according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,    
  196    respectively.  A zone that does not include these records according     
  197    to the rules in this section is an unsigned zone.                       
  198                                                                            
  199    DNSSEC requires a change to the definition of the CNAME resource        
  200    record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG    
  201    and NSEC RRs to appear at the same owner name as does a CNAME RR.       
  202                                                                            
  203    DNSSEC specifies the placement of two new RR types, NSEC and DS,        
  204    which can be placed at the parental side of a zone cut (that is, at a   
  205    delegation point).  This is an exception to the general prohibition     
  206    against putting data in the parent zone at a zone cut.  Section 2.6     
  207    describes this change.                                                  
  208                                                                            
  209                                                                            
  210                                                                            
  211                                                                            
  212                                                                            
  213                                                                            
  214                                                                            
  215                                                                            
  216                                                                            
  217 Arends, et al.              Standards Track                     [Page 4]   

  218 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  219                                                                            
  220                                                                            
  221 2.1.  Including DNSKEY RRs in a Zone                                       
  222                                                                            
  223    To sign a zone, the zone's administrator generates one or more          
  224    public/private key pairs and uses the private key(s) to sign            
  225    authoritative RRsets in the zone.  For each private key used to         
  226    create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR    
  227    containing the corresponding public key.  A zone key DNSKEY RR MUST     
  228    have the Zone Key bit of the flags RDATA field set (see Section 2.1.1   
  229    of [RFC4034]).  Public keys associated with other DNS operations MAY    
  230    be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT   
  231    be used to verify RRSIGs.                                               
  232                                                                            
  233    If the zone administrator intends a signed zone to be usable other      
  234    than as an island of security, the zone apex MUST contain at least      
  235    one DNSKEY RR to act as a secure entry point into the zone.  This       
  236    secure entry point could then be used as the target of a secure         
  237    delegation via a corresponding DS RR in the parent zone (see            
  238    [RFC4034]).                                                             
  239                                                                            
  240 2.2.  Including RRSIG RRs in a Zone                                        
  241                                                                            
  242    For each authoritative RRset in a signed zone, there MUST be at least   
  243    one RRSIG record that meets the following requirements:                 
  244                                                                            
  245    o  The RRSIG owner name is equal to the RRset owner name.               
  246                                                                            
  247    o  The RRSIG class is equal to the RRset class.                         
  248                                                                            
  249    o  The RRSIG Type Covered field is equal to the RRset type.             
  250                                                                            
  251    o  The RRSIG Original TTL field is equal to the TTL of the RRset.       
  252                                                                            
  253    o  The RRSIG RR's TTL is equal to the TTL of the RRset.                 
  254                                                                            
  255    o  The RRSIG Labels field is equal to the number of labels in the       
  256       RRset owner name, not counting the null root label and not           
  257       counting the leftmost label if it is a wildcard.                     
  258                                                                            
  259    o  The RRSIG Signer's Name field is equal to the name of the zone       
  260       containing the RRset.                                                
  261                                                                            
  262    o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a    
  263       zone key DNSKEY record at the zone apex.                             
  264                                                                            
  265    The process for constructing the RRSIG RR for a given RRset is          
  266    described in [RFC4034].  An RRset MAY have multiple RRSIG RRs           
  267    associated with it.  Note that as RRSIG RRs are closely tied to the     
  268    RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS   
  269                                                                            
  270                                                                            
  271                                                                            
  272 Arends, et al.              Standards Track                     [Page 5]   

  273 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  274                                                                            
  275                                                                            
  276    RR types, do not form RRsets.  In particular, the TTL values among      
  277    RRSIG RRs with a common owner name do not follow the RRset rules        
  278    described in [RFC2181].                                                 
  279                                                                            
  280    An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would     
  281    add no value and would create an infinite loop in the signing           
  282    process.                                                                
  283                                                                            
  284    The NS RRset that appears at the zone apex name MUST be signed, but     
  285    the NS RRsets that appear at delegation points (that is, the NS         
  286    RRsets in the parent zone that delegate the name to the child zone's    
  287    name servers) MUST NOT be signed.  Glue address RRsets associated       
  288    with delegations MUST NOT be signed.                                    
  289                                                                            
line-5 Mark Andrews(Technical Erratum #3044) [Verified]
based on outdated version
Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                       VeriSign
It should say:
Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3007, 3597, 3226                                             VeriSign

4033, 4034 and 4035 all list 3007 as being updated but none update 3007
  290    There MUST be an RRSIG for each RRset using at least one DNSKEY of      
  291    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset    
  292    itself MUST be signed by each algorithm appearing in the DS RRset       
  293    located at the delegating parent (if any).                              
  294                                                                            

Section 5.11 of RFC6840 says:

The last paragraph of Section 2.2 of [RFC4035] includes rules
describing which algorithms must be used to sign a zone.  Since these
rules have been confusing, they are restated using different language
here:

   The DS RRset and DNSKEY RRset are used to signal which algorithms
   are used to sign a zone.  The presence of an algorithm in either a
   zone's DS or DNSKEY RRset signals that that algorithm is used to
   sign the entire zone.

   A signed zone MUST include a DNSKEY for each algorithm present in
   the zone's DS RRset and expected trust anchors for the zone.  The
   zone MUST also be signed with each algorithm (though not each key)
   present in the DNSKEY RRset.  It is possible to add algorithms at
   the DNSKEY that aren't in the DS record, but not vice versa.  If
   more than one key of the same algorithm is in the DNSKEY RRset, it
   is sufficient to sign each RRset with any subset of these DNSKEYs.
   It is acceptable to sign some RRsets with one subset of keys (or
   key) and other RRsets with a different subset, so long as at least
   one DNSKEY of each algorithm is used to sign each RRset.
   Likewise, if there are DS records for multiple keys of the same
   algorithm, any subset of those may appear in the DNSKEY RRset.

This requirement applies to servers, not validators.  Validators
SHOULD accept any single valid path.  They SHOULD NOT insist that all
algorithms signaled in the DS RRset work, and they MUST NOT insist
that all algorithms signaled in the DNSKEY RRset work.  A validator
MAY have a configuration option to perform a signature completeness
test to support troubleshooting.

  295 2.3.  Including NSEC RRs in a Zone                                         
  296                                                                            
  297    Each owner name in the zone that has authoritative data or a            
  298    delegation point NS RRset MUST have an NSEC resource record.  The       
  299    format of NSEC RRs and the process for constructing the NSEC RR for a   
  300    given name is described in [RFC4034].                                   
  301                                                                            

Section 3 of RFC4470 says:

The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
bits set and SHOULD NOT have any other bits set.  This relaxes the
requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
names that did not exist before the zone was signed.

  302    The TTL value for any NSEC RR SHOULD be the same as the minimum TTL     
  303    value field in the zone SOA RR.                                         
  304                                                                            
  305    An NSEC record (and its associated RRSIG RRset) MUST NOT be the only    
  306    RRset at any particular owner name.  That is, the signing process       
  307    MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not    
  308    the owner name of any RRset before the zone was signed.  The main       
  309    reasons for this are a desire for namespace consistency between         
  310    signed and unsigned versions of the same zone and a desire to reduce    
  311    the risk of response inconsistency in security oblivious recursive      
  312    name servers.                                                           
  313                                                                            
  314    The type bitmap of every NSEC resource record in a signed zone MUST     
  315    indicate the presence of both the NSEC record itself and its            
  316    corresponding RRSIG record.                                             
  317                                                                            
  318    The difference between the set of owner names that require RRSIG        
  319    records and the set of owner names that require NSEC records is         
  320    subtle and worth highlighting.  RRSIG records are present at the        
  321    owner names of all authoritative RRsets.  NSEC records are present at   
  322    the owner names of all names for which the signed zone is               
  323    authoritative and also at the owner names of delegations from the       
  324                                                                            
  325                                                                            
  326                                                                            
  327 Arends, et al.              Standards Track                     [Page 6]   

  328 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  329                                                                            
  330                                                                            
  331    signed zone to its children.  Neither NSEC nor RRSIG records are        
  332    present (in the parent zone) at the owner names of glue address         
  333    RRsets.  Note, however, that this distinction is for the most part      
  334    visible only during the zone signing process, as NSEC RRsets are        
  335    authoritative data and are therefore signed.  Thus, any owner name      
  336    that has an NSEC RRset will have RRSIG RRs as well in the signed        
  337    zone.                                                                   
  338                                                                            
  339    The bitmap for the NSEC RR at a delegation point requires special       
  340    attention.  Bits corresponding to the delegation NS RRset and any       
  341    RRsets for which the parent zone has authoritative data MUST be set;    
  342    bits corresponding to any non-NS RRset for which the parent is not      
  343    authoritative MUST be clear.                                            
  344                                                                            
  345 2.4.  Including DS RRs in a Zone                                           
  346                                                                            
  347    The DS resource record establishes authentication chains between DNS    
  348    zones.  A DS RRset SHOULD be present at a delegation point when the     
  349    child zone is signed.  The DS RRset MAY contain multiple records,       
  350    each referencing a public key in the child zone used to verify the      
  351    RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS    
  352    RRsets MUST NOT appear at a zone's apex.                                
  353                                                                            
  354    A DS RR SHOULD point to a DNSKEY RR that is present in the child's      
  355    apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed   
  356    by the corresponding private key.  DS RRs that fail to meet these       
  357    conditions are not useful for validation, but because the DS RR and     
  358    its corresponding DNSKEY RR are in different zones, and because the     
  359    DNS is only loosely consistent, temporary mismatches can occur.         
  360                                                                            
  361    The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset   
  362    (that is, the NS RRset from the same zone containing the DS RRset).     
  363                                                                            
  364    Construction of a DS RR requires knowledge of the corresponding         
  365    DNSKEY RR in the child zone, which implies communication between the    
  366    child and parent zones.  This communication is an operational matter    
  367    not covered by this document.                                           
  368                                                                            
  369 2.5.  Changes to the CNAME Resource Record                                 
  370                                                                            
  371    If a CNAME RRset is present at a name in a signed zone, appropriate     
  372    RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that   
  373    name for secure dynamic update purposes is also allowed ([RFC3007]).    
  374    Other types MUST NOT be present at that name.                           
  375                                                                            
  376    This is a modification to the original CNAME definition given in        
  377    [RFC1034].  The original definition of the CNAME RR did not allow any   
  378    other types to coexist with a CNAME record, but a signed zone           
  379                                                                            
  380                                                                            
  381                                                                            
  382 Arends, et al.              Standards Track                     [Page 7]   

  383 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  384                                                                            
  385                                                                            
  386    requires NSEC and RRSIG RRs for every authoritative name.  To resolve   
  387    this conflict, this specification modifies the definition of the        
  388    CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.   
  389                                                                            
  390 2.6.  DNSSEC RR Types Appearing at Zone Cuts                               
  391                                                                            
  392    DNSSEC introduced two new RR types that are unusual in that they can    
  393    appear at the parental side of a zone cut.  At the parental side of a   
  394    zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at     
  395    the owner name.  A DS RR could also be present if the zone being        
  396    delegated is signed and seeks to have a chain of authentication to      
  397    the parent zone.  This is an exception to the original DNS              
  398    specification ([RFC1034]), which states that only NS RRsets could       
  399    appear at the parental side of a zone cut.                              
  400                                                                            
  401    This specification updates the original DNS specification to allow      
  402    NSEC and DS RR types at the parent side of a zone cut.  These RRsets    
  403    are authoritative for the parent when they appear at the parent side    
  404    of a zone cut.                                                          
  405                                                                            
  406 2.7.  Example of a Secure Zone                                             
  407                                                                            
  408    Appendix A shows a complete example of a small signed zone.             
  409                                                                            
  410 3.  Serving                                                                
  411                                                                            
  412    This section describes the behavior of entities that include            
  413    security-aware name server functions.  In many cases such functions     
  414    will be part of a security-aware recursive name server, but a           
  415    security-aware authoritative name server has some of the same           
  416    requirements.  Functions specific to security-aware recursive name      
  417    servers are described in Section 3.2; functions specific to             
  418    authoritative servers are described in Section 3.1.                     
  419                                                                            
  420    In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"   
  421    are as used in [RFC1034].                                               
  422                                                                            
  423    A security-aware name server MUST support the EDNS0 ([RFC2671])         
  424    message size extension, MUST support a message size of at least 1220    
  425    octets, and SHOULD support a message size of 4000 octets.  As IPv6      
  426    packets can only be fragmented by the source host, a security aware     
  427    name server SHOULD take steps to ensure that UDP datagrams it           
  428    transmits over IPv6 are fragmented, if necessary, at the minimum IPv6   
  429    MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],    
  430    and [RFC3226] for further discussion of packet size and fragmentation   
  431    issues.                                                                 
  432                                                                            
  433                                                                            
  434                                                                            
  435                                                                            
  436                                                                            
  437 Arends, et al.              Standards Track                     [Page 8]   

  438 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  439                                                                            
  440                                                                            
  441    A security-aware name server that receives a DNS query that does not    
  442    include the EDNS OPT pseudo-RR or that has the DO bit clear MUST        
  443    treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and   
  444    MUST NOT perform any of the additional processing described below.      
  445    Because the DS RR type has the peculiar property of only existing in    
  446    the parent zone at delegation points, DS RRs always require some        
  447    special processing, as described in Section 3.1.4.1.                    
  448                                                                            
  449    Security aware name servers that receive explicit queries for           
  450    security RR types that match the content of more than one zone that     
  451    it serves (for example, NSEC and RRSIG RRs above and below a            
  452    delegation point where the server is authoritative for both zones)      
  453    should behave self-consistently.  As long as the response is always     
  454    consistent for each query to the name server, the name server MAY       
  455    return one of the following:                                            
  456                                                                            
  457    o  The above-delegation RRsets.                                         
  458    o  The below-delegation RRsets.                                         
  459    o  Both above and below-delegation RRsets.                              
  460    o  Empty answer section (no records).                                   
  461    o  Some other response.                                                 
  462    o  An error.                                                            
  463                                                                            
  464    DNSSEC allocates two new bits in the DNS message header: the CD         
  465    (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit    
  466    is controlled by resolvers; a security-aware name server MUST copy      
  467    the CD bit from a query into the corresponding response.  The AD bit    
  468    is controlled by name servers; a security-aware name server MUST        
  469    ignore the setting of the AD bit in queries.  See Sections 3.1.6,       
  470    3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.     
  471                                                                            
  472    A security aware name server that synthesizes CNAME RRs from DNAME      
  473    RRs as described in [RFC2672] SHOULD NOT generate signatures for the    
  474    synthesized CNAME RRs.                                                  
  475                                                                            
  476 3.1.  Authoritative Name Servers                                           
  477                                                                            
  478    Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT       
  479    pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name   
  480    server for a signed zone MUST include additional RRSIG, NSEC, and DS    
  481    RRs, according to the following rules:                                  
  482                                                                            
  483    o  RRSIG RRs that can be used to authenticate a response MUST be        
  484       included in the response according to the rules in Section 3.1.1.    
  485                                                                            
  486                                                                            
  487                                                                            
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Arends, et al.              Standards Track                     [Page 9]   

  493 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  494                                                                            
  495                                                                            
  496    o  NSEC RRs that can be used to provide authenticated denial of         
  497       existence MUST be included in the response automatically according   
  498       to the rules in Section 3.1.3.                                       
  499                                                                            
  500    o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST    
  501       be included in referrals automatically according to the rules in     
  502       Section 3.1.4.                                                       
  503                                                                            
  504    These rules only apply to responses where the semantics convey          
  505    information about the presence or absence of resource records.  That    
  506    is, these rules are not intended to rule out responses such as RCODE    
  507    4 ("Not Implemented") or RCODE 5 ("Refused").                           
  508                                                                            
  509    DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5   
  510    discusses zone transfer requirements.                                   
  511                                                                            
  512 3.1.1.  Including RRSIG RRs in a Response                                  
  513                                                                            
  514    When responding to a query that has the DO bit set, a security-aware    
  515    authoritative name server SHOULD attempt to send RRSIG RRs that a       
  516    security-aware resolver can use to authenticate the RRsets in the       
  517    response.  A name server SHOULD make every attempt to keep the RRset    
  518    and its associated RRSIG(s) together in a response.  Inclusion of       
  519    RRSIG RRs in a response is subject to the following rules:              
  520                                                                            
  521    o  When placing a signed RRset in the Answer section, the name server   
  522       MUST also place its RRSIG RRs in the Answer section.  The RRSIG      
  523       RRs have a higher priority for inclusion than any other RRsets       
  524       that may have to be included.  If space does not permit inclusion    
  525       of these RRSIG RRs, the name server MUST set the TC bit.             
  526                                                                            
  527    o  When placing a signed RRset in the Authority section, the name       
  528       server MUST also place its RRSIG RRs in the Authority section.       
  529       The RRSIG RRs have a higher priority for inclusion than any other    
  530       RRsets that may have to be included.  If space does not permit       
  531       inclusion of these RRSIG RRs, the name server MUST set the TC bit.   
  532                                                                            
  533    o  When placing a signed RRset in the Additional section, the name      
  534       server MUST also place its RRSIG RRs in the Additional section.      
  535       If space does not permit inclusion of both the RRset and its         
  536       associated RRSIG RRs, the name server MAY retain the RRset while     
  537       dropping the RRSIG RRs.  If this happens, the name server MUST NOT   
  538       set the TC bit solely because these RRSIG RRs didn't fit.            
  539                                                                            
  540                                                                            
  541                                                                            
  542                                                                            
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Arends, et al.              Standards Track                    [Page 10]   

  548 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  549                                                                            
  550                                                                            
  551 3.1.2.  Including DNSKEY RRs in a Response                                 
  552                                                                            
  553    When responding to a query that has the DO bit set and that requests    
  554    the SOA or NS RRs at the apex of a signed zone, a security-aware        
  555    authoritative name server for that zone MAY return the zone apex        
  556    DNSKEY RRset in the Additional section.  In this situation, the         
  557    DNSKEY RRset and associated RRSIG RRs have lower priority than does     
  558    any other information that would be placed in the additional section.   
  559    The name server SHOULD NOT include the DNSKEY RRset unless there is     
  560    enough space in the response message for both the DNSKEY RRset and      
  561    its associated RRSIG RR(s).  If there is not enough space to include    
  562    these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST     
  563    NOT set the TC bit solely because these RRs didn't fit (see Section     
  564    3.1.1).                                                                 
  565                                                                            
  566 3.1.3.  Including NSEC RRs in a Response                                   
  567                                                                            
  568    When responding to a query that has the DO bit set, a security-aware    
  569    authoritative name server for a signed zone MUST include NSEC RRs in    
  570    each of the following cases:                                            
  571                                                                            
  572    No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>    
  573       but does not contain any RRsets that exactly match <SNAME, SCLASS,   
  574       STYPE>.                                                              
  575                                                                            
  576    Name Error: The zone does not contain any RRsets that match <SNAME,     
  577       SCLASS> either exactly or via wildcard name expansion.               
  578                                                                            
  579    Wildcard Answer: The zone does not contain any RRsets that exactly      
  580       match <SNAME, SCLASS> but does contain an RRset that matches         
  581       <SNAME, SCLASS, STYPE> via wildcard name expansion.                  
  582                                                                            
  583    Wildcard No Data: The zone does not contain any RRsets that exactly     
  584       match <SNAME, SCLASS> and does contain one or more RRsets that       
  585       match <SNAME, SCLASS> via wildcard name expansion, but does not      
  586       contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard    
  587       name expansion.                                                      
  588                                                                            
  589    In each of these cases, the name server includes NSEC RRs in the        
  590    response to prove that an exact match for <SNAME, SCLASS, STYPE> was    
  591    not present in the zone and that the response that the name server is   
  592    returning is correct given the data in the zone.                        
  593                                                                            
  594                                                                            
  595                                                                            
  596                                                                            
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Arends, et al.              Standards Track                    [Page 11]   

  603 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  604                                                                            
  605                                                                            
  606 3.1.3.1.  Including NSEC RRs: No Data Response                             
  607                                                                            
  608    If the zone contains RRsets matching <SNAME, SCLASS> but contains no    
  609    RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST        
  610    include the NSEC RR for <SNAME, SCLASS> along with its associated       
  611    RRSIG RR(s) in the Authority section of the response (see Section       
  612    3.1.1).  If space does not permit inclusion of the NSEC RR or its       
  613    associated RRSIG RR(s), the name server MUST set the TC bit (see        
  614    Section 3.1.1).                                                         
  615                                                                            
  616    Since the search name exists, wildcard name expansion does not apply    
  617    to this query, and a single signed NSEC RR suffices to prove that the   
  618    requested RR type does not exist.                                       
  619                                                                            
  620 3.1.3.2.  Including NSEC RRs: Name Error Response                          
  621                                                                            
  622    If the zone does not contain any RRsets matching <SNAME, SCLASS>        
  623    either exactly or via wildcard name expansion, then the name server     
  624    MUST include the following NSEC RRs in the Authority section, along     
  625    with their associated RRSIG RRs:                                        
  626                                                                            
  627    o  An NSEC RR proving that there is no exact match for <SNAME,          
  628       SCLASS>.                                                             
  629                                                                            
  630    o  An NSEC RR proving that the zone contains no RRsets that would       
  631       match <SNAME, SCLASS> via wildcard name expansion.                   
  632                                                                            
  633    In some cases, a single NSEC RR may prove both of these points.  If     
  634    it does, the name server SHOULD only include the NSEC RR and its        
  635    RRSIG RR(s) once in the Authority section.                              
  636                                                                            
  637    If space does not permit inclusion of these NSEC and RRSIG RRs, the     
  638    name server MUST set the TC bit (see Section 3.1.1).                    
  639                                                                            
  640    The owner names of these NSEC and RRSIG RRs are not subject to          
  641    wildcard name expansion when these RRs are included in the Authority    
  642    section of the response.                                                
  643                                                                            
  644    Note that this form of response includes cases in which SNAME           
  645    corresponds to an empty non-terminal name within the zone (a name       
  646    that is not the owner name for any RRset but that is the parent name    
  647    of one or more RRsets).                                                 
  648                                                                            
  649 3.1.3.3.  Including NSEC RRs: Wildcard Answer Response                     
  650                                                                            
  651    If the zone does not contain any RRsets that exactly match <SNAME,      
  652    SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>   
  653    via wildcard name expansion, the name server MUST include the           
  654                                                                            
  655                                                                            
  656                                                                            
  657 Arends, et al.              Standards Track                    [Page 12]   

  658 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  659                                                                            
  660                                                                            
  661    wildcard-expanded answer and the corresponding wildcard-expanded        
  662    RRSIG RRs in the Answer section and MUST include in the Authority       
  663    section an NSEC RR and associated RRSIG RR(s) proving that the zone     
  664    does not contain a closer match for <SNAME, SCLASS>.  If space does     
  665    not permit inclusion of the answer, NSEC and RRSIG RRs, the name        
  666    server MUST set the TC bit (see Section 3.1.1).                         
  667                                                                            
  668 3.1.3.4.  Including NSEC RRs: Wildcard No Data Response                    
  669                                                                            
  670    This case is a combination of the previous cases.  The zone does not    
  671    contain an exact match for <SNAME, SCLASS>, and although the zone       
  672    does contain RRsets that match <SNAME, SCLASS> via wildcard             
  673    expansion, none of those RRsets matches STYPE.  The name server MUST    
  674    include the following NSEC RRs in the Authority section, along with     
  675    their associated RRSIG RRs:                                             
  676                                                                            
  677    o  An NSEC RR proving that there are no RRsets matching STYPE at the    
  678       wildcard owner name that matched <SNAME, SCLASS> via wildcard        
  679       expansion.                                                           
  680                                                                            
  681    o  An NSEC RR proving that there are no RRsets in the zone that would   
  682       have been a closer match for <SNAME, SCLASS>.                        
  683                                                                            
  684    In some cases, a single NSEC RR may prove both of these points.  If     
  685    it does, the name server SHOULD only include the NSEC RR and its        
  686    RRSIG RR(s) once in the Authority section.                              
  687                                                                            
  688    The owner names of these NSEC and RRSIG RRs are not subject to          
  689    wildcard name expansion when these RRs are included in the Authority    
  690    section of the response.                                                
  691                                                                            
  692    If space does not permit inclusion of these NSEC and RRSIG RRs, the     
  693    name server MUST set the TC bit (see Section 3.1.1).                    
  694                                                                            
  695 3.1.3.5.  Finding the Right NSEC RRs                                       
  696                                                                            
  697    As explained above, there are several situations in which a             
  698    security-aware authoritative name server has to locate an NSEC RR       
  699    that proves that no RRsets matching a particular SNAME exist.           
  700    Locating such an NSEC RR within an authoritative zone is relatively     
  701    simple, at least in concept.  The following discussion assumes that     
  702    the name server is authoritative for the zone that would have held      
  703    the non-existent RRsets matching SNAME.  The algorithm below is         
  704    written for clarity, not for efficiency.                                
  705                                                                            
  706    To find the NSEC that proves that no RRsets matching name N exist in    
  707    the zone Z that would have held them, construct a sequence, S,          
  708    consisting of the owner names of every RRset in Z, sorted into          
  709                                                                            
  710                                                                            
  711                                                                            
  712 Arends, et al.              Standards Track                    [Page 13]   

  713 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  714                                                                            
  715                                                                            
  716    canonical order ([RFC4034]), with no duplicate names.  Find the name    
  717    M that would have immediately preceded N in S if any RRsets with        
  718    owner name N had existed.  M is the owner name of the NSEC RR that      
  719    proves that no RRsets exist with owner name N.                          
  720                                                                            
  721    The algorithm for finding the NSEC RR that proves that a given name     
  722    is not covered by any applicable wildcard is similar but requires an    
  723    extra step.  More precisely, the algorithm for finding the NSEC         
  724    proving that no RRsets exist with the applicable wildcard name is       
  725    precisely the same as the algorithm for finding the NSEC RR that        
  726    proves that RRsets with any other owner name do not exist.  The part    
  727    that's missing is a method of determining the name of the non-          
  728    existent applicable wildcard.  In practice, this is easy, because the   
  729    authoritative name server has already checked for the presence of       
  730    precisely this wildcard name as part of step (1)(c) of the normal       
  731    lookup algorithm described in Section 4.3.2 of [RFC1034].               
  732                                                                            
  733 3.1.4.  Including DS RRs in a Response                                     
  734                                                                            
  735    When responding to a query that has the DO bit set, a security-aware    
  736    authoritative name server returning a referral includes DNSSEC data     
  737    along with the NS RRset.                                                
  738                                                                            
  739    If a DS RRset is present at the delegation point, the name server       
  740    MUST return both the DS RRset and its associated RRSIG RR(s) in the     
  741    Authority section along with the NS RRset.                              
  742                                                                            
  743    If no DS RRset is present at the delegation point, the name server      
  744    MUST return both the NSEC RR that proves that the DS RRset is not       
  745    present and the NSEC RR's associated RRSIG RR(s) along with the NS      
  746    RRset.  The name server MUST place the NS RRset before the NSEC RRset   
  747    and its associated RRSIG RR(s).                                         
  748                                                                            
  749    Including these DS, NSEC, and RRSIG RRs increases the size of           
  750    referral messages and may cause some or all glue RRs to be omitted.     
  751    If space does not permit inclusion of the DS or NSEC RRset and          
  752    associated RRSIG RRs, the name server MUST set the TC bit (see          
  753    Section 3.1.1).                                                         
  754                                                                            
  755 3.1.4.1.  Responding to Queries for DS RRs                                 
  756                                                                            
  757    The DS resource record type is unusual in that it appears only on the   
  758    parent zone's side of a zone cut.  For example, the DS RRset for the    
  759    delegation of "foo.example" is stored in the "example" zone rather      
  760    than in the "foo.example" zone.  This requires special processing       
  761    rules for both name servers and resolvers, as the name server for the   
  762    child zone is authoritative for the name at the zone cut by the         
  763    normal DNS rules but the child zone does not contain the DS RRset.      
  764                                                                            
  765                                                                            
  766                                                                            
  767 Arends, et al.              Standards Track                    [Page 14]   

  768 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  769                                                                            
  770                                                                            
  771    A security-aware resolver sends queries to the parent zone when         
  772    looking for a needed DS RR at a delegation point (see Section 4.2).     
  773    However, special rules are necessary to avoid confusing                 
  774    security-oblivious resolvers which might become involved in             
  775    processing such a query (for example, in a network configuration that   
  776    forces a security-aware resolver to channel its queries through a       
  777    security-oblivious recursive name server).  The rest of this section    
  778    describes how a security-aware name server processes DS queries in      
  779    order to avoid this problem.                                            
  780                                                                            

RFC9077 updates many RFCs to clarify how TTLs are calculated when using DNSSEC. For RFC 4035, it replaces:

The TTL value for any NSEC RR SHOULD be the same as the minimum
TTL value field in the zone SOA RR.

with:

The TTL of the NSEC RR that is returned MUST be the lesser of the
MINIMUM field of the SOA record and the TTL of the SOA itself.
This matches the definition of the TTL for negative responses in
[RFC2308].  Because some signers incrementally update the NSEC
chain, a transient inconsistency between the observed and expected
TTL MAY exist.

  781    The need for special processing by a security-aware name server only    
  782    arises when all the following conditions are met:                       
  783                                                                            
  784    o  The name server has received a query for the DS RRset at a zone      
  785       cut.                                                                 
  786                                                                            
  787    o  The name server is authoritative for the child zone.                 
  788                                                                            
  789    o  The name server is not authoritative for the parent zone.            
  790                                                                            
  791    o  The name server does not offer recursion.                            
  792                                                                            
  793    In all other cases, the name server either has some way of obtaining    
  794    the DS RRset or could not have been expected to have the DS RRset       
  795    even by the pre-DNSSEC processing rules, so the name server can         
  796    return either the DS RRset or an error response according to the        
  797    normal processing rules.                                                
  798                                                                            
  799    If all the above conditions are met, however, the name server is        
  800    authoritative for SNAME but cannot supply the requested RRset.  In      
  801    this case, the name server MUST return an authoritative "no data"       
  802    response showing that the DS RRset does not exist in the child zone's   
  803    apex.  See Appendix B.8 for an example of such a response.              
  804                                                                            
  805 3.1.5.  Responding to Queries for Type AXFR or IXFR                        
  806                                                                            
  807    DNSSEC does not change the DNS zone transfer process.  A signed zone    
  808    will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these    
  809    records have no special meaning with respect to a zone transfer         
  810    operation.                                                              
  811                                                                            
  812    An authoritative name server is not required to verify that a zone is   
  813    properly signed before sending or accepting a zone transfer.            
  814    However, an authoritative name server MAY choose to reject the entire   
  815    zone transfer if the zone fails to meet any of the signing              
  816    requirements described in Section 2.  The primary objective of a zone   
  817    transfer is to ensure that all authoritative name servers have          
  818    identical copies of the zone.  An authoritative name server that        
  819                                                                            
  820                                                                            
  821                                                                            
  822 Arends, et al.              Standards Track                    [Page 15]   

  823 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  824                                                                            
  825                                                                            
  826    chooses to perform its own zone validation MUST NOT selectively         
  827    reject some RRs and accept others.                                      
  828                                                                            
  829    DS RRsets appear only on the parental side of a zone cut and are        
  830    authoritative data in the parent zone.  As with any other               
  831    authoritative RRset, the DS RRset MUST be included in zone transfers    
  832    of the zone in which the RRset is authoritative data.  In the case of   
  833    the DS RRset, this is the parent zone.                                  
  834                                                                            
  835    NSEC RRs appear in both the parent and child zones at a zone cut and    
  836    are authoritative data in both the parent and child zones.  The         
  837    parental and child NSEC RRs at a zone cut are never identical to each   
  838    other, as the NSEC RR in the child zone's apex will always indicate     
  839    the presence of the child zone's SOA RR whereas the parental NSEC RR    
  840    at the zone cut will never indicate the presence of an SOA RR.  As      
  841    with any other authoritative RRs, NSEC RRs MUST be included in zone     
  842    transfers of the zone in which they are authoritative data.  The        
  843    parental NSEC RR at a zone cut MUST be included in zone transfers of    
  844    the parent zone, and the NSEC at the zone apex of the child zone MUST   
  845    be included in zone transfers of the child zone.                        
  846                                                                            
  847    RRSIG RRs appear in both the parent and child zones at a zone cut and   
  848    are authoritative in whichever zone contains the authoritative RRset    
  849    for which the RRSIG RR provides the signature.  That is, the RRSIG RR   
  850    for a DS RRset or a parental NSEC RR at a zone cut will be              
  851    authoritative in the parent zone, and the RRSIG for any RRset in the    
  852    child zone's apex will be authoritative in the child zone.  Parental    
  853    and child RRSIG RRs at a zone cut will never be identical to each       
  854    other, as the Signer's Name field of an RRSIG RR in the child zone's    
  855    apex will indicate a DNSKEY RR in the child zone's apex whereas the     
  856    same field of a parental RRSIG RR at the zone cut will indicate a       
  857    DNSKEY RR in the parent zone's apex.  As with any other authoritative   
  858    RRs, RRSIG RRs MUST be included in zone transfers of the zone in        
  859    which they are authoritative data.                                      
  860                                                                            
  861 3.1.6.  The AD and CD Bits in an Authoritative Response                    
  862                                                                            
  863    The CD and AD bits are designed for use in communication between        
  864    security-aware resolvers and security-aware recursive name servers.     
  865    These bits are for the most part not relevant to query processing by    
  866    security-aware authoritative name servers.                              
  867                                                                            
  868    A security-aware name server does not perform signature validation      
  869    for authoritative data during query processing, even when the CD bit    
  870    is clear.  A security-aware name server SHOULD clear the CD bit when    
  871    composing an authoritative response.                                    
  872                                                                            
  873                                                                            
  874                                                                            
  875                                                                            
  876                                                                            
  877 Arends, et al.              Standards Track                    [Page 16]   

  878 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  879                                                                            
  880                                                                            
  881    A security-aware name server MUST NOT set the AD bit in a response      
  882    unless the name server considers all RRsets in the Answer and           
  883    Authority sections of the response to be authentic.  A security-aware   
  884    name server's local policy MAY consider data from an authoritative      
  885    zone to be authentic without further validation.  However, the name     
  886    server MUST NOT do so unless the name server obtained the               
  887    authoritative zone via secure means (such as a secure zone transfer     
  888    mechanism) and MUST NOT do so unless this behavior has been             
  889    configured explicitly.                                                  
  890                                                                            
  891    A security-aware name server that supports recursion MUST follow the    
  892    rules for the CD and AD bits given in Section 3.2 when generating a     
  893    response that involves data obtained via recursion.                     
  894                                                                            
  895 3.2.  Recursive Name Servers                                               
  896                                                                            
  897    As explained in [RFC4033], a security-aware recursive name server is    
  898    an entity that acts in both the security-aware name server and          
  899    security-aware resolver roles.  This section uses the terms "name       
  900    server side" and "resolver side" to refer to the code within a          
  901    security-aware recursive name server that implements the                
  902    security-aware name server role and the code that implements the        
  903    security-aware resolver role, respectively.                             
  904                                                                            
  905    The resolver side follows the usual rules for caching and negative      
  906    caching that would apply to any security-aware resolver.                
  907                                                                            
  908 3.2.1.  The DO Bit                                                         
  909                                                                            
  910    The resolver side of a security-aware recursive name server MUST set    
  911    the DO bit when sending requests, regardless of the state of the DO     
  912    bit in the initiating request received by the name server side.  If     
  913    the DO bit in an initiating query is not set, the name server side      
  914    MUST strip any authenticating DNSSEC RRs from the response but MUST     
  915    NOT strip any DNSSEC RR types that the initiating query explicitly      
  916    requested.                                                              
  917                                                                            
line-781 Peter van Dijk(Technical Erratum #5226) [Reported]
based on outdated version
   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zone.

   o  The name server does not offer recursion.
It should say:
   The need for special processing by a security-aware name server only
   arises when all the following conditions are met:

   o  The name server has received a query for the DS RRset at a zone
      cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zoneany zone above the
      child's apex.

   o  The name server does not offer recursion.

The original text is ambiguous in the face of an authoritative server having zones C.B.A. and A. but not B.A., and could cause DS queries for C to return a NODATA at C's apex, instead of the desired referral to B. which would allow resolution to continue correctly.
  918 3.2.2.  The CD Bit                                                         
  919                                                                            
  920    The CD bit exists in order to allow a security-aware resolver to        
  921    disable signature validation in a security-aware name server's          
  922    processing of a particular query.                                       
  923                                                                            
  924    The name server side MUST copy the setting of the CD bit from a query   
  925    to the corresponding response.                                          
  926                                                                            
  927    The name server side of a security-aware recursive name server MUST     
  928    pass the state of the CD bit to the resolver side along with the rest   
  929                                                                            
  930                                                                            
  931                                                                            
  932 Arends, et al.              Standards Track                    [Page 17]   

  933 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  934                                                                            
  935                                                                            
  936    of an initiating query, so that the resolver side will know whether     
  937    it is required to verify the response data it returns to the name       
  938    server side.  If the CD bit is set, it indicates that the originating   
  939    resolver is willing to perform whatever authentication its local        
  940    policy requires.  Thus, the resolver side of the recursive name         
  941    server need not perform authentication on the RRsets in the response.   
  942    When the CD bit is set, the recursive name server SHOULD, if            
  943    possible, return the requested data to the originating resolver, even   
  944    if the recursive name server's local authentication policy would        
  945    reject the records in question.  That is, by setting the CD bit, the    
  946    originating resolver has indicated that it takes responsibility for     
  947    performing its own authentication, and the recursive name server        
  948    should not interfere.                                                   
  949                                                                            
  950    If the resolver side implements a BAD cache (see Section 4.7) and the   
  951    name server side receives a query that matches an entry in the          
  952    resolver side's BAD cache, the name server side's response depends on   
  953    the state of the CD bit in the original query.  If the CD bit is set,   
  954    the name server side SHOULD return the data from the BAD cache; if      
  955    the CD bit is not set, the name server side MUST return RCODE 2         
  956    (server failure).                                                       
  957                                                                            
  958    The intent of the above rule is to provide the raw data to clients      
  959    that are capable of performing their own signature verification         
  960    checks while protecting clients that depend on the resolver side of a   
  961    security-aware recursive name server to perform such checks.  Several   
  962    of the possible reasons why signature validation might fail involve     
  963    conditions that may not apply equally to the recursive name server      
  964    and the client that invoked it.  For example, the recursive name        
  965    server's clock may be set incorrectly, or the client may have           
  966    knowledge of a relevant island of security that the recursive name      
  967    server does not share.  In such cases, "protecting" a client that is    
  968    capable of performing its own signature validation from ever seeing     
  969    the "bad" data does not help the client.                                
  970                                                                            

Section 5.9 of RFC6840 says:

When processing a request with the Checking Disabled (CD) bit set, a
resolver SHOULD attempt to return all response data, even data that
has failed DNSSEC validation.  Section 3.2.2 of [RFC4035] requires a
resolver processing a request with the CD bit set to set the CD bit
on its upstream queries.

This document further specifies that validating resolvers SHOULD set
the CD bit on every upstream query.  This is regardless of whether
the CD bit was set on the incoming query or whether it has a trust
anchor at or above the QNAME.

[RFC4035] is ambiguous about what to do when a cached response was
obtained with the CD bit unset, a case that only arises when the
resolver chooses not to set the CD bit on all upstream queries, as
specified above.  In the typical case, no new query is required, nor
does the cache need to track the state of the CD bit used to make a
given query.  The problem arises when the cached response is a server
failure (RCODE 2), which may indicate that the requested data failed
DNSSEC validation at an upstream validating resolver.  ([RFC2308]
permits caching of server failures for up to five minutes.)  In these
cases, a new query with the CD bit set is required.

Be sure to read Appendix B of RFC6840, which details the logic behind the recommendation to alwas set the CD bit on queries.

  971 3.2.3.  The AD Bit                                                         
  972                                                                            
  973    The name server side of a security-aware recursive name server MUST     
  974    NOT set the AD bit in a response unless the name server considers all   
  975    RRsets in the Answer and Authority sections of the response to be       
  976    authentic.  The name server side SHOULD set the AD bit if and only if   
  977    the resolver side considers all RRsets in the Answer section and any    
  978    relevant negative response RRs in the Authority section to be           
  979    authentic.  The resolver side MUST follow the procedure described in    
  980    Section 5 to determine whether the RRs in question are authentic.       
  981    However, for backward compatibility, a recursive name server MAY set    
  982    the AD bit when a response includes unsigned CNAME RRs if those CNAME   
  983                                                                            
  984                                                                            
  985                                                                            
  986                                                                            
  987 Arends, et al.              Standards Track                    [Page 18]   

  988 RFC 4035             DNSSEC Protocol Modifications            March 2005   
  989                                                                            
  990                                                                            
  991    RRs demonstrably could have been synthesized from an authentic DNAME    
  992    RR that is also included in the response according to the synthesis     
  993    rules described in [RFC2672].                                           
  994                                                                            
  995 3.3.  Example DNSSEC Responses                                             
  996                                                                            
  997    See Appendix B for example response packets.                            
  998                                                                            
  999 4.  Resolving                                                              
 1000                                                                            
 1001    This section describes the behavior of entities that include            
 1002    security-aware resolver functions.  In many cases such functions will   
 1003    be part of a security-aware recursive name server, but a stand-alone    
 1004    security-aware resolver has many of the same requirements.  Functions   
 1005    specific to security-aware recursive name servers are described in      
 1006    Section 3.2.                                                            
 1007                                                                            
 1008 4.1.  EDNS Support                                                         
 1009                                                                            
 1010    A security-aware resolver MUST include an EDNS ([RFC2671]) OPT          
 1011    pseudo-RR with the DO ([RFC3225]) bit set when sending queries.         
 1012                                                                            
 1013    A security-aware resolver MUST support a message size of at least       
 1014    1220 octets, SHOULD support a message size of 4000 octets, and MUST     
 1015    use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR     
 1016    to advertise the message size that it is willing to accept.  A          
 1017    security-aware resolver's IP layer MUST handle fragmented UDP packets   
 1018    correctly regardless of whether any such fragmented packets were        
 1019    received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and        
 1020    [RFC3226] for discussion of these requirements.                         
 1021                                                                            
 1022 4.2.  Signature Verification Support                                       
 1023                                                                            
 1024    A security-aware resolver MUST support the signature verification       
 1025    mechanisms described in Section 5 and SHOULD apply them to every        
 1026    received response, except when:                                         
 1027                                                                            
 1028    o  the security-aware resolver is part of a security-aware recursive    
 1029       name server, and the response is the result of recursion on behalf   
 1030       of a query received with the CD bit set;                             
 1031                                                                            
 1032    o  the response is the result of a query generated directly via some    
 1033       form of application interface that instructed the security-aware     
 1034       resolver not to perform validation for this query; or                
 1035                                                                            
 1036    o  validation for this query has been disabled by local policy.         
 1037                                                                            
 1038                                                                            
 1039                                                                            
 1040                                                                            
 1041                                                                            
 1042 Arends, et al.              Standards Track                    [Page 19]   

 1043 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1044                                                                            
 1045                                                                            
 1046    A security-aware resolver's support for signature verification MUST     
 1047    include support for verification of wildcard owner names.               
 1048                                                                            
 1049    Security-aware resolvers MAY query for missing security RRs in an       
 1050    attempt to perform validation; implementations that choose to do so     
 1051    must be aware that the answers received may not be sufficient to        
 1052    validate the original response.  For example, a zone update may have    
 1053    changed (or deleted) the desired information between the original and   
 1054    follow-up queries.                                                      
 1055                                                                            
 1056    When attempting to retrieve missing NSEC RRs that reside on the         
 1057    parental side at a zone cut, a security-aware iterative-mode resolver   
 1058    MUST query the name servers for the parent zone, not the child zone.    
 1059                                                                            
 1060    When attempting to retrieve a missing DS, a security-aware              
 1061    iterative-mode resolver MUST query the name servers for the parent      
 1062    zone, not the child zone.  As explained in Section 3.1.4.1,             
 1063    security-aware name servers need to apply special processing rules to   
 1064    handle the DS RR, and in some situations the resolver may also need     
 1065    to apply special rules to locate the name servers for the parent zone   
 1066    if the resolver does not already have the parent's NS RRset.  To        
 1067    locate the parent NS RRset, the resolver can start with the             
 1068    delegation name, strip off the leftmost label, and query for an NS      
 1069    RRset by that name.  If no NS RRset is present at that name, the        
 1070    resolver then strips off the leftmost remaining label and retries the   
 1071    query for that name, repeating this process of walking up the tree      
 1072    until it either finds the NS RRset or runs out of labels.               
 1073                                                                            
 1074 4.3.  Determining Security Status of Data                                  
 1075                                                                            
 1076    A security-aware resolver MUST be able to determine whether it should   
 1077    expect a particular RRset to be signed.  More precisely, a              
 1078    security-aware resolver must be able to distinguish between four        
 1079    cases:                                                                  
 1080                                                                            
 1081    Secure: An RRset for which the resolver is able to build a chain of     
 1082       signed DNSKEY and DS RRs from a trusted security anchor to the       
 1083       RRset.  In this case, the RRset should be signed and is subject to   
 1084       signature validation, as described above.                            
 1085                                                                            
 1086    Insecure: An RRset for which the resolver knows that it has no chain    
 1087       of signed DNSKEY and DS RRs from any trusted starting point to the   
 1088       RRset.  This can occur when the target RRset lies in an unsigned     
 1089       zone or in a descendent of an unsigned zone.  In this case, the      
 1090       RRset may or may not be signed, but the resolver will not be able    
 1091       to verify the signature.                                             
 1092                                                                            
 1093                                                                            
 1094                                                                            
 1095                                                                            
 1096                                                                            
 1097 Arends, et al.              Standards Track                    [Page 20]   

 1098 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1099                                                                            
 1100                                                                            
 1101    Bogus: An RRset for which the resolver believes that it ought to be     
 1102       able to establish a chain of trust but for which it is unable to     
 1103       do so, either due to signatures that for some reason fail to         
 1104       validate or due to missing data that the relevant DNSSEC RRs         
 1105       indicate should be present.  This case may indicate an attack but    
 1106       may also indicate a configuration error or some form of data         
 1107       corruption.                                                          
 1108                                                                            
 1109    Indeterminate: An RRset for which the resolver is not able to           
 1110       determine whether the RRset should be signed, as the resolver is     
 1111       not able to obtain the necessary DNSSEC RRs.  This can occur when    
 1112       the security-aware resolver is not able to contact security-aware    
 1113       name servers for the relevant zones.                                 
 1114                                                                            
 1115 4.4.  Configured Trust Anchors                                             
 1116                                                                            
 1117    A security-aware resolver MUST be capable of being configured with at   
 1118    least one trusted public key or DS RR and SHOULD be capable of being    
 1119    configured with multiple trusted public keys or DS RRs.  Since a        
 1120    security-aware resolver will not be able to validate signatures         
 1121    without such a configured trust anchor, the resolver SHOULD have some   
 1122    reasonably robust mechanism for obtaining such keys when it boots;      
 1123    examples of such a mechanism would be some form of non-volatile         
 1124    storage (such as a disk drive) or some form of trusted local network    
 1125    configuration mechanism.                                                
 1126                                                                            
 1127    Note that trust anchors also cover key material that is updated in a    
 1128    secure manner.  This secure manner could be through physical media, a   
 1129    key exchange protocol, or some other out-of-band means.                 
 1130                                                                            
 1131 4.5.  Response Caching                                                     
 1132                                                                            
 1133    A security-aware resolver SHOULD cache each response as a single        
 1134    atomic entry containing the entire answer, including the named RRset    
 1135    and any associated DNSSEC RRs.  The resolver SHOULD discard the         
 1136    entire atomic entry when any of the RRs contained in it expire.  In     
 1137    most cases the appropriate cache index for the atomic entry will be     
 1138    the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response    
 1139    form described in Section 3.1.3.2 the appropriate cache index will be   
 1140    the double <QNAME,QCLASS>.                                              
 1141                                                                            
 1142    The reason for these recommendations is that, between the initial       
 1143    query and the expiration of the data from the cache, the                
 1144    authoritative data might have been changed (for example, via dynamic    
 1145    update).                                                                
 1146                                                                            
 1147                                                                            
 1148                                                                            
 1149                                                                            
 1150                                                                            
 1151                                                                            
 1152 Arends, et al.              Standards Track                    [Page 21]   

 1153 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1154                                                                            
 1155                                                                            
 1156    There are two situations for which this is relevant:                    
 1157                                                                            
 1158    1.  By using the RRSIG record, it is possible to deduce that an         
 1159        answer was synthesized from a wildcard.  A security-aware           
 1160        recursive name server could store this wildcard data and use it     
 1161        to generate positive responses to queries other than the name for   
 1162        which the original answer was first received.                       
 1163                                                                            
 1164    2.  NSEC RRs received to prove the non-existence of a name could be     
 1165        reused by a security-aware resolver to prove the non-existence of   
 1166        any name in the name range it spans.                                
 1167                                                                            

Section 5.8 of RFC6840 says:

Section 3.2.3 of [RFC4035] describes under which conditions a
validating resolver should set or clear the AD bit in a response.  In
order to interoperate with legacy stub resolvers and middleboxes that
neither understand nor ignore the AD bit, validating resolvers SHOULD
only set the AD bit when a response both meets the conditions listed
in Section 3.2.3 of [RFC4035], and the request contained either a set
DO bit or a set AD bit.

 1168    In theory, a resolver could use wildcards or NSEC RRs to generate       
 1169    positive and negative responses (respectively) until the TTL or         
 1170    signatures on the records in question expire.  However, it seems        
 1171    prudent for resolvers to avoid blocking new authoritative data or       
 1172    synthesizing new data on their own.  Resolvers that follow this         
 1173    recommendation will have a more consistent view of the namespace.       
 1174                                                                            

The abstract of RFC8198 says "This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards." In specific, it replaces this pargraph ("In theory, a resolver...") with:

Once the records are validated, DNSSEC-enabled validating 
resolvers SHOULD use wildcards and NSEC/NSEC3 resource records
to generate positive and negative responses until the
effective TTLs or signatures for those records expire.

 1175 4.6.  Handling of the CD and AD Bits                                       
 1176                                                                            
 1177    A security-aware resolver MAY set a query's CD bit in order to          
 1178    indicate that the resolver takes responsibility for performing          
 1179    whatever authentication its local policy requires on the RRsets in      
 1180    the response.  See Section 3.2 for the effect this bit has on the       
 1181    behavior of security-aware recursive name servers.                      
 1182                                                                            
 1183    A security-aware resolver MUST clear the AD bit when composing query    
 1184    messages to protect against buggy name servers that blindly copy        
 1185    header bits that they do not understand from the query message to the   
 1186    response message.                                                       
 1187                                                                            
 1188    A resolver MUST disregard the meaning of the CD and AD bits in a        
 1189    response unless the response was obtained by using a secure channel     
 1190    or the resolver was specifically configured to regard the message       
 1191    header bits without using a secure channel.                             
 1192                                                                            

Section 5.7 of RFC6840 says:

The semantics of the Authentic Data (AD) bit in the query were
previously undefined.  Section 4.6 of [RFC4035] instructed resolvers
to always clear the AD bit when composing queries.

This document defines setting the AD bit in a query as a signal
indicating that the requester understands and is interested in the
value of the AD bit in the response.  This allows a requester to
indicate that it understands the AD bit without also requesting
DNSSEC data via the DO bit.

Further, Section 5.8 of RFC6840 says:

Section 3.2.3 of [RFC4035] describes under which conditions a
validating resolver should set or clear the AD bit in a response.  In
order to interoperate with legacy stub resolvers and middleboxes that
neither understand nor ignore the AD bit, validating resolvers SHOULD
only set the AD bit when a response both meets the conditions listed
in Section 3.2.3 of [RFC4035], and the request contained either a set
DO bit or a set AD bit.

 1193 4.7.  Caching BAD Data                                                     
 1194                                                                            
 1195    While many validation errors will be transient, some are likely to be   
 1196    more persistent, such as those caused by administrative error           
 1197    (failure to re-sign a zone, clock skew, and so forth).  Since           
 1198    requerying will not help in these cases, validating resolvers might     
 1199    generate a significant amount of unnecessary DNS traffic as a result    
 1200    of repeated queries for RRsets with persistent validation failures.     
 1201                                                                            
 1202    To prevent such unnecessary DNS traffic, security-aware resolvers MAY   
 1203    cache data with invalid signatures, with some restrictions.             
 1204                                                                            
 1205                                                                            
 1206                                                                            
 1207 Arends, et al.              Standards Track                    [Page 22]   

 1208 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1209                                                                            
 1210                                                                            
 1211    Conceptually, caching such data is similar to negative caching          
 1212    ([RFC2308]), except that instead of caching a valid negative            
 1213    response, the resolver is caching the fact that a particular answer     
 1214    failed to validate.  This document refers to a cache of data with       
 1215    invalid signatures as a "BAD cache".                                    
 1216                                                                            
 1217    Resolvers that implement a BAD cache MUST take steps to prevent the     
 1218    cache from being useful as a denial-of-service attack amplifier,        
 1219    particularly the following:                                             
 1220                                                                            
 1221    o  Since RRsets that fail to validate do not have trustworthy TTLs,     
 1222       the implementation MUST assign a TTL.  This TTL SHOULD be small,     
 1223       in order to mitigate the effect of caching the results of an         
 1224       attack.                                                              
 1225                                                                            
 1226    o  In order to prevent caching of a transient validation failure        
 1227       (which might be the result of an attack), resolvers SHOULD track     
 1228       queries that result in validation failures and SHOULD only answer    
 1229       from the BAD cache after the number of times that responses to       
 1230       queries for that particular <QNAME, QTYPE, QCLASS> have failed to    
 1231       validate exceeds a threshold value.                                  
 1232                                                                            
 1233    Resolvers MUST NOT return RRsets from the BAD cache unless the          
 1234    resolver is not required to validate the signatures of the RRsets in    
 1235    question under the rules given in Section 4.2 of this document.  See    
 1236    Section 3.2.2 for discussion of how the responses returned by a         
 1237    security-aware recursive name server interact with a BAD cache.         
 1238                                                                            
 1239 4.8.  Synthesized CNAMEs                                                   
 1240                                                                            
 1241    A validating security-aware resolver MUST treat the signature of a      
 1242    valid signed DNAME RR as also covering unsigned CNAME RRs that could    
 1243    have been synthesized from the DNAME RR, as described in [RFC2672],     
 1244    at least to the extent of not rejecting a response message solely       
 1245    because it contains such CNAME RRs.  The resolver MAY retain such       
 1246    CNAME RRs in its cache or in the answers it hands back, but is not      
 1247    required to do so.                                                      
 1248                                                                            
 1249 4.9.  Stub Resolvers                                                       
 1250                                                                            
 1251    A security-aware stub resolver MUST support the DNSSEC RR types, at     
 1252    least to the extent of not mishandling responses just because they      
 1253    contain DNSSEC RRs.                                                     
 1254                                                                            
 1255                                                                            
 1256                                                                            
 1257                                                                            
 1258                                                                            
 1259                                                                            
 1260                                                                            
 1261                                                                            
 1262 Arends, et al.              Standards Track                    [Page 23]   

 1263 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1264                                                                            
 1265                                                                            
 1266 4.9.1.  Handling of the DO Bit                                             
 1267                                                                            
 1268    A non-validating security-aware stub resolver MAY include the DNSSEC    
 1269    RRs returned by a security-aware recursive name server as part of the   
 1270    data that the stub resolver hands back to the application that          
 1271    invoked it, but is not required to do so.  A non-validating stub        
 1272    resolver that seeks to do this will need to set the DO bit in order     
 1273    to receive DNSSEC RRs from the recursive name server.                   
 1274                                                                            
 1275    A validating security-aware stub resolver MUST set the DO bit,          
 1276    because otherwise it will not receive the DNSSEC RRs it needs to        
 1277    perform signature validation.                                           
 1278                                                                            
 1279 4.9.2.  Handling of the CD Bit                                             
 1280                                                                            
 1281    A non-validating security-aware stub resolver SHOULD NOT set the CD     
 1282    bit when sending queries unless it is requested by the application      
 1283    layer, as by definition, a non-validating stub resolver depends on      
 1284    the security-aware recursive name server to perform validation on its   
 1285    behalf.                                                                 
 1286                                                                            
 1287    A validating security-aware stub resolver SHOULD set the CD bit,        
 1288    because otherwise the security-aware recursive name server will         
 1289    answer the query using the name server's local policy, which may        
 1290    prevent the stub resolver from receiving data that would be             
 1291    acceptable to the stub resolver's local policy.                         
 1292                                                                            
 1293 4.9.3.  Handling of the AD Bit                                             
 1294                                                                            
 1295    A non-validating security-aware stub resolver MAY chose to examine      
 1296    the setting of the AD bit in response messages that it receives in      
 1297    order to determine whether the security-aware recursive name server     
 1298    that sent the response claims to have cryptographically verified the    
 1299    data in the Answer and Authority sections of the response message.      
 1300    Note, however, that the responses received by a security-aware stub     
 1301    resolver are heavily dependent on the local policy of the               
 1302    security-aware recursive name server.  Therefore, there may be little   
 1303    practical value in checking the status of the AD bit, except perhaps    
 1304    as a debugging aid.  In any case, a security-aware stub resolver MUST   
 1305    NOT place any reliance on signature validation allegedly performed on   
 1306    its behalf, except when the security-aware stub resolver obtained the   
 1307    data in question from a trusted security-aware recursive name server    
 1308    via a secure channel.                                                   
 1309                                                                            
 1310    A validating security-aware stub resolver SHOULD NOT examine the        
 1311    setting of the AD bit in response messages, as, by definition, the      
 1312    stub resolver performs its own signature validation regardless of the   
 1313    setting of the AD bit.                                                  
 1314                                                                            
 1315                                                                            
 1316                                                                            
 1317 Arends, et al.              Standards Track                    [Page 24]   

 1318 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1319                                                                            
 1320                                                                            

Section 3.1 of RFC6840 says:

Section 4.7 of [RFC4035] permits security-aware resolvers to
implement a BAD cache.  That guidance has changed: security-aware
resolvers SHOULD implement a BAD cache as described in [RFC4035].

This change in guidance is based on operational experience with
DNSSEC administrative errors leading to significant increases in DNS
traffic, with an accompanying realization that such events are more
likely and more damaging than originally supposed.  An example of one
such event is documented in "Rolling Over DNSSEC Keys" [Huston].

 1321 5.  Authenticating DNS Responses                                           
 1322                                                                            
 1323    To use DNSSEC RRs for authentication, a security-aware resolver         
 1324    requires configured knowledge of at least one authenticated DNSKEY or   
 1325    DS RR.  The process for obtaining and authenticating this initial       
 1326    trust anchor is achieved via some external mechanism.  For example, a   
 1327    resolver could use some off-line authenticated exchange to obtain a     
 1328    zone's DNSKEY RR or to obtain a DS RR that identifies and               
 1329    authenticates a zone's DNSKEY RR.  The remainder of this section        
 1330    assumes that the resolver has somehow obtained an initial set of        
 1331    trust anchors.                                                          
 1332                                                                            
 1333    An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY   
 1334    RRset.  To authenticate an apex DNSKEY RRset by using an initial key,   
 1335    the resolver MUST:                                                      
 1336                                                                            
 1337    1.  verify that the initial DNSKEY RR appears in the apex DNSKEY        
 1338        RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA   
 1339        bit 7) set; and                                                     
 1340                                                                            
 1341    2.  verify that there is some RRSIG RR that covers the apex DNSKEY      
 1342        RRset, and that the combination of the RRSIG RR and the initial     
 1343        DNSKEY RR authenticates the DNSKEY RRset.  The process for using    
 1344        an RRSIG RR to authenticate an RRset is described in Section 5.3.   
 1345                                                                            
 1346    Once the resolver has authenticated the apex DNSKEY RRset by using an   
 1347    initial DNSKEY RR, delegations from that zone can be authenticated by   
 1348    using DS RRs.  This allows a resolver to start from an initial key      
 1349    and use DS RRsets to proceed recursively down the DNS tree, obtaining   
 1350    other apex DNSKEY RRsets.  If the resolver were configured with a       
 1351    root DNSKEY RR, and if every delegation had a DS RR associated with     
 1352    it, then the resolver could obtain and validate any apex DNSKEY         
 1353    RRset.  The process of using DS RRs to authenticate referrals is        
 1354    described in Section 5.2.                                               
 1355                                                                            
 1356    Section 5.3 shows how the resolver can use DNSKEY RRs in the apex       
 1357    DNSKEY RRset and RRSIG RRs from the zone to authenticate any other      
 1358    RRsets in the zone once the resolver has authenticated a zone's apex    
 1359    DNSKEY RRset.  Section 5.4 shows how the resolver can use               
 1360    authenticated NSEC RRsets from the zone to prove that an RRset is not   
 1361    present in the zone.                                                    
 1362                                                                            
 1363    When a resolver indicates support for DNSSEC (by setting the DO bit),   
 1364    a security-aware name server should attempt to provide the necessary    
 1365    DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).       
 1366    However, a security-aware resolver may still receive a response that    
 1367    lacks the appropriate DNSSEC RRs, whether due to configuration issues   
 1368    such as an upstream security-oblivious recursive name server that       
 1369                                                                            
 1370                                                                            
 1371                                                                            
 1372 Arends, et al.              Standards Track                    [Page 25]   

 1373 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1374                                                                            
 1375                                                                            
 1376    accidentally interferes with DNSSEC RRs or due to a deliberate attack   
 1377    in which an adversary forges a response, strips DNSSEC RRs from a       
 1378    response, or modifies a query so that DNSSEC RRs appear not to be       
 1379    requested.  The absence of DNSSEC data in a response MUST NOT by        
 1380    itself be taken as an indication that no authentication information     
 1381    exists.                                                                 
 1382                                                                            
 1383    A resolver SHOULD expect authentication information from signed         
 1384    zones.  A resolver SHOULD believe that a zone is signed if the          
 1385    resolver has been configured with public key information for the        
 1386    zone, or if the zone's parent is signed and the delegation from the     
 1387    parent contains a DS RRset.                                             
 1388                                                                            
 1389 5.1.  Special Considerations for Islands of Security                       
 1390                                                                            
 1391    Islands of security (see [RFC4033]) are signed zones for which it is    
 1392    not possible to construct an authentication chain to the zone from      
 1393    its parent.  Validating signatures within an island of security         
 1394    requires that the validator have some other means of obtaining an       
 1395    initial authenticated zone key for the island.  If a validator cannot   
 1396    obtain such a key, it SHOULD switch to operating as if the zones in     
 1397    the island of security are unsigned.                                    
 1398                                                                            
 1399    All the normal processes for validating responses apply to islands of   
 1400    security.  The only difference between normal validation and            
 1401    validation within an island of security is in how the validator         
 1402    obtains a trust anchor for the authentication chain.                    
 1403                                                                            

Section 4.3 of RFC6840 says:

Section 5 of [RFC4035] says nothing explicit about validating
responses based on (or that should be based on) CNAMEs.  When
validating a NOERROR/NODATA response, validators MUST check the CNAME
bit in the matching NSEC or NSEC3 RR's type bitmap in addition to the
bit for the query type.

Without this check, an attacker could successfully transform a
positive CNAME response into a NOERROR/NODATA response by (for
example) simply stripping the CNAME RRset from the response.  A naive
validator would then note that the QTYPE was not present in the
matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was
set; thus, the response should have been a positive CNAME response.

 1404 5.2.  Authenticating Referrals                                             
 1405                                                                            
 1406    Once the apex DNSKEY RRset for a signed parent zone has been            
 1407    authenticated, DS RRsets can be used to authenticate the delegation     
 1408    to a signed child zone.  A DS RR identifies a DNSKEY RR in the child    
 1409    zone's apex DNSKEY RRset and contains a cryptographic digest of the     
 1410    child zone's DNSKEY RR.  Use of a strong cryptographic digest           
 1411    algorithm ensures that it is computationally infeasible for an          
 1412    adversary to generate a DNSKEY RR that matches the digest.  Thus,       
 1413    authenticating the digest allows a resolver to authenticate the         
 1414    matching DNSKEY RR.  The resolver can then use this child DNSKEY RR     
 1415    to authenticate the entire child apex DNSKEY RRset.                     
 1416                                                                            
 1417    Given a DS RR for a delegation, the child zone's apex DNSKEY RRset      
 1418    can be authenticated if all of the following hold:                      
 1419                                                                            
 1420    o  The DS RR has been authenticated using some DNSKEY RR in the         
 1421       parent's apex DNSKEY RRset (see Section 5.3).                        
 1422                                                                            
 1423                                                                            
 1424                                                                            
 1425                                                                            
 1426                                                                            
 1427 Arends, et al.              Standards Track                    [Page 26]   

 1428 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1429                                                                            
 1430                                                                            
 1431    o  The Algorithm and Key Tag in the DS RR match the Algorithm field     
 1432       and the key tag of a DNSKEY RR in the child zone's apex DNSKEY       
 1433       RRset, and, when the DNSKEY RR's owner name and RDATA are hashed     
 1434       using the digest algorithm specified in the DS RR's Digest Type      
 1435       field, the resulting digest value matches the Digest field of the    
 1436       DS RR.                                                               
 1437                                                                            
 1438    o  The matching DNSKEY RR in the child zone has the Zone Flag bit       
 1439       set, the corresponding private key has signed the child zone's       
 1440       apex DNSKEY RRset, and the resulting RRSIG RR authenticates the      
 1441       child zone's apex DNSKEY RRset.                                      
 1442                                                                            
 1443    If the referral from the parent zone did not contain a DS RRset, the    
 1444    response should have included a signed NSEC RRset proving that no DS    
 1445    RRset exists for the delegated name (see Section 3.1.4).  A             
 1446    security-aware resolver MUST query the name servers for the parent      
 1447    zone for the DS RRset if the referral includes neither a DS RRset nor   
 1448    a NSEC RRset proving that the DS RRset does not exist (see Section      
 1449    4).                                                                     
 1450                                                                            
 1451    If the validator authenticates an NSEC RRset that proves that no DS     
 1452    RRset is present for this zone, then there is no authentication path    
 1453    leading from the parent to the child.  If the resolver has an initial   
 1454    DNSKEY or DS RR that belongs to the child zone or to any delegation     
 1455    below the child zone, this initial DNSKEY or DS RR MAY be used to       
 1456    re-establish an authentication path.  If no such initial DNSKEY or DS   
 1457    RR exists, the validator cannot authenticate RRsets in or below the     
 1458    child zone.                                                             
 1459                                                                            

Section 4.4 of RFC6840 says:

Section 5.2 of [RFC4035] specifies that a validator, when proving a
delegation is not secure, needs to check for the absence of the DS
and SOA bits in the NSEC (or NSEC3) type bitmap.  The validator also
MUST check for the presence of the NS bit in the matching NSEC (or
NSEC3) RR (proving that there is, indeed, a delegation), or
alternately make sure that the delegation is covered by an NSEC3 RR
with the Opt-Out flag set.

Without this check, an attacker could reuse an NSEC or NSEC3 RR
matching a non-delegation name to spoof an unsigned delegation at
that name.  This would claim that an existing signed RRset (or set of
signed RRsets) is below an unsigned delegation, thus not signed and
vulnerable to further attack.

Section 5.3 of RFC6840 gives an extensive discussion of how to handle zones that are signed with private algorithms. It extends the processing given in Section 5.2 of RFC 4035.

 1460    If the validator does not support any of the algorithms listed in an    
 1461    authenticated DS RRset, then the resolver has no supported              
 1462    authentication path leading from the parent to the child.  The          
 1463    resolver should treat this case as it would the case of an              
 1464    authenticated NSEC RRset proving that no DS RRset exists, as            
 1465    described above.                                                        
 1466                                                                            
 1467    Note that, for a signed delegation, there are two NSEC RRs associated   
 1468    with the delegated name.  One NSEC RR resides in the parent zone and    
 1469    can be used to prove whether a DS RRset exists for the delegated        
 1470    name.  The second NSEC RR resides in the child zone and identifies      
 1471    which RRsets are present at the apex of the child zone.  The parent     
 1472    NSEC RR and child NSEC RR can always be distinguished because the SOA   
 1473    bit will be set in the child NSEC RR and clear in the parent NSEC RR.   
 1474    A security-aware resolver MUST use the parent NSEC RR when attempting   
 1475    to prove that a DS RRset does not exist.                                
 1476                                                                            
 1477                                                                            
 1478                                                                            
 1479                                                                            
 1480                                                                            
 1481                                                                            
 1482 Arends, et al.              Standards Track                    [Page 27]   

 1483 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1484                                                                            
 1485                                                                            
 1486    If the resolver does not support any of the algorithms listed in an     
 1487    authenticated DS RRset, then the resolver will not be able to verify    
 1488    the authentication path to the child zone.  In this case, the           
 1489    resolver SHOULD treat the child zone as if it were unsigned.            
 1490                                                                            

Section 5.2 of RFC6840 says:

In other words, when determining the security status of a zone, a
validator disregards any authenticated DS records that specify
unknown or unsupported DNSKEY algorithms.  If none are left, the zone
is treated as if it were unsigned.

This document modifies the above text to additionally disregard
authenticated DS records using unknown or unsupported message digest
algorithms.

 1491 5.3.  Authenticating an RRset with an RRSIG RR                             
 1492                                                                            
 1493    A validator can use an RRSIG RR and its corresponding DNSKEY RR to      
 1494    attempt to authenticate RRsets.  The validator first checks the RRSIG   
 1495    RR to verify that it covers the RRset, has a valid time interval, and   
 1496    identifies a valid DNSKEY RR.  The validator then constructs the        
 1497    canonical form of the signed data by appending the RRSIG RDATA          
 1498    (excluding the Signature Field) with the canonical form of the          
 1499    covered RRset.  Finally, the validator uses the public key and          
 1500    signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,      
 1501    and 5.3.3 describe each step in detail.                                 
 1502                                                                            
 1503 5.3.1.  Checking the RRSIG RR Validity                                     
 1504                                                                            
 1505    A security-aware resolver can use an RRSIG RR to authenticate an        
 1506    RRset if all of the following conditions hold:                          
 1507                                                                            
 1508    o  The RRSIG RR and the RRset MUST have the same owner name and the     
 1509       same class.                                                          
 1510                                                                            
 1511    o  The RRSIG RR's Signer's Name field MUST be the name of the zone      
 1512       that contains the RRset.                                             
 1513                                                                            
 1514    o  The RRSIG RR's Type Covered field MUST equal the RRset's type.       
 1515                                                                            
 1516    o  The number of labels in the RRset owner name MUST be greater than    
 1517       or equal to the value in the RRSIG RR's Labels field.                
 1518                                                                            
 1519    o  The validator's notion of the current time MUST be less than or      
 1520       equal to the time listed in the RRSIG RR's Expiration field.         
 1521                                                                            
 1522    o  The validator's notion of the current time MUST be greater than or   
 1523       equal to the time listed in the RRSIG RR's Inception field.          
 1524                                                                            
 1525    o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST     
 1526       match the owner name, algorithm, and key tag for some DNSKEY RR in   
 1527       the zone's apex DNSKEY RRset.                                        
 1528                                                                            
 1529    o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY     
 1530       RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)     
 1531       set.                                                                 
 1532                                                                            
 1533                                                                            
 1534                                                                            
 1535                                                                            
 1536                                                                            
 1537 Arends, et al.              Standards Track                    [Page 28]   

 1538 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1539                                                                            
 1540                                                                            
 1541    It is possible for more than one DNSKEY RR to match the conditions      
 1542    above.  In this case, the validator cannot predetermine which DNSKEY    
 1543    RR to use to authenticate the signature, and it MUST try each           
 1544    matching DNSKEY RR until either the signature is validated or the       
 1545    validator has run out of matching public keys to try.                   
 1546                                                                            
 1547    Note that this authentication process is only meaningful if the         
 1548    validator authenticates the DNSKEY RR before using it to validate       
 1549    signatures.  The matching DNSKEY RR is considered to be authentic if:   
 1550                                                                            
 1551    o  the apex DNSKEY RRset containing the DNSKEY RR is considered         
 1552       authentic; or                                                        
 1553                                                                            
 1554    o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,   
 1555       and the DNSKEY RR either matches an authenticated DS RR from the     
 1556       parent zone or matches a trust anchor.                               
 1557                                                                            
 1558 5.3.2.  Reconstructing the Signed Data                                     
 1559                                                                            
 1560    Once the RRSIG RR has met the validity requirements described in        
 1561    Section 5.3.1, the validator has to reconstruct the original signed     
 1562    data.  The original signed data includes RRSIG RDATA (excluding the     
 1563    Signature field) and the canonical form of the RRset.  Aside from       
 1564    being ordered, the canonical form of the RRset might also differ from   
 1565    the received RRset due to DNS name compression, decremented TTLs, or    
 1566    wildcard expansion.  The validator should use the following to          
 1567    reconstruct the original signed data:                                   
 1568                                                                            
 1569          signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where               
 1570                                                                            
 1571             "|" denotes concatenation                                      
 1572                                                                            
 1573             RRSIG_RDATA is the wire format of the RRSIG RDATA fields       
 1574                with the Signature field excluded and the Signer's Name     
 1575                in canonical form.                                          
 1576                                                                            
 1577             RR(i) = name | type | class | OrigTTL | RDATA length | RDATA   
 1578                                                                            
 1579                name is calculated according to the function below          
 1580                                                                            
 1581                class is the RRset's class                                  
 1582                                                                            
 1583                type is the RRset type and all RRs in the class             
 1584                                                                            
 1585                OrigTTL is the value from the RRSIG Original TTL field      
 1586                                                                            
 1587                All names in the RDATA field are in canonical form          
 1588                                                                            
 1589                                                                            
 1590                                                                            
 1591                                                                            
 1592 Arends, et al.              Standards Track                    [Page 29]   

 1593 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1594                                                                            
 1595                                                                            
 1596                The set of all RR(i) is sorted into canonical order.        
 1597                                                                            
 1598             To calculate the name:                                         
 1599                let rrsig_labels = the value of the RRSIG Labels field      
 1600                                                                            
 1601                let fqdn = RRset's fully qualified domain name in           
 1602                                canonical form                              
 1603                                                                            
 1604                let fqdn_labels = Label count of the fqdn above.            
 1605                                                                            
 1606                if rrsig_labels = fqdn_labels,                              
 1607                    name = fqdn                                             
 1608                                                                            
 1609                if rrsig_labels < fqdn_labels,                              
 1610                   name = "*." | the rightmost rrsig_label labels of the    
 1611                                 fqdn                                       
 1612                                                                            
 1613                if rrsig_labels > fqdn_labels                               
 1614                   the RRSIG RR did not pass the necessary validation       
 1615                   checks and MUST NOT be used to authenticate this         
 1616                   RRset.                                                   
 1617                                                                            
 1618    The canonical forms for names and RRsets are defined in [RFC4034].      
 1619                                                                            
 1620    NSEC RRsets at a delegation boundary require special processing.        
 1621    There are two distinct NSEC RRsets associated with a signed delegated   
 1622    name.  One NSEC RRset resides in the parent zone, and specifies which   
 1623    RRsets are present at the parent zone.  The second NSEC RRset resides   
 1624    at the child zone and identifies which RRsets are present at the apex   
 1625    in the child zone.  The parent NSEC RRset and child NSEC RRset can      
 1626    always be distinguished as only a child NSEC RR will indicate that an   
 1627    SOA RRset exists at the name.  When reconstructing the original NSEC    
 1628    RRset for the delegation from the parent zone, the NSEC RRs MUST NOT    
 1629    be combined with NSEC RRs from the child zone.  When reconstructing     
 1630    the original NSEC RRset for the apex of the child zone, the NSEC RRs    
 1631    MUST NOT be combined with NSEC RRs from the parent zone.                
 1632                                                                            
 1633    Note that each of the two NSEC RRsets at a delegation point has a       
 1634    corresponding RRSIG RR with an owner name matching the delegated        
 1635    name, and each of these RRSIG RRs is authoritative data associated      
 1636    with the same zone that contains the corresponding NSEC RRset.  If      
 1637    necessary, a resolver can tell these RRSIG RRs apart by checking the    
 1638    Signer's Name field.                                                    
 1639                                                                            
 1640                                                                            
 1641                                                                            
 1642                                                                            
 1643                                                                            
 1644                                                                            
 1645                                                                            
 1646                                                                            
 1647 Arends, et al.              Standards Track                    [Page 30]   

 1648 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1649                                                                            
 1650                                                                            

Section 4.2 of RFC6840 says:

[RFC4035] does not address how to validate responses when QTYPE=*.
As described in Section 6.2.2 of [RFC1034], a proper response to
QTYPE=* may include a subset of the RRsets at a given name.  That is,
it is not necessary to include all RRsets at the QNAME in the
response.

When validating a response to QTYPE=*, all received RRsets that match
QNAME and QCLASS MUST be validated.  If any of those RRsets fail
validation, the answer is considered Bogus.  If there are no RRsets
matching QNAME and QCLASS, that fact MUST be validated according to
the rules in Section 5.4 of [RFC4035] (as clarified in this
document).  To be clear, a validator must not expect to receive all
records at the QNAME in response to QTYPE=*.

 1651 5.3.3.  Checking the Signature                                             
 1652                                                                            
 1653    Once the resolver has validated the RRSIG RR as described in Section    
 1654    5.3.1 and reconstructed the original signed data as described in        
 1655    Section 5.3.2, the validator can attempt to use the cryptographic       
 1656    signature to authenticate the signed data, and thus (finally!)          
 1657    authenticate the RRset.                                                 
 1658                                                                            
 1659    The Algorithm field in the RRSIG RR identifies the cryptographic        
 1660    algorithm used to generate the signature.  The signature itself is      
 1661    contained in the Signature field of the RRSIG RDATA, and the public     
 1662    key used to verify the signature is contained in the Public Key field   
 1663    of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]       
 1664    provides a list of algorithm types and provides pointers to the         
 1665    documents that define each algorithm's use.                             
 1666                                                                            
 1667    Note that it is possible for more than one DNSKEY RR to match the       
 1668    conditions in Section 5.3.1.  In this case, the validator can only      
 1669    determine which DNSKEY RR is correct by trying each matching public     
 1670    key until the validator either succeeds in validating the signature     
 1671    or runs out of keys to try.                                             
 1672                                                                            
 1673    If the Labels field of the RRSIG RR is not equal to the number of       
 1674    labels in the RRset's fully qualified owner name, then the RRset is     
 1675    either invalid or the result of wildcard expansion.  The resolver       
 1676    MUST verify that wildcard expansion was applied properly before         
 1677    considering the RRset to be authentic.  Section 5.3.4 describes how     
 1678    to determine whether a wildcard was applied properly.                   
 1679                                                                            
 1680    If other RRSIG RRs also cover this RRset, the local resolver security   
 1681    policy determines whether the resolver also has to test these RRSIG     
 1682    RRs and how to resolve conflicts if these RRSIG RRs lead to differing   
 1683    results.                                                                
 1684                                                                            
 1685    If the resolver accepts the RRset as authentic, the validator MUST      
 1686    set the TTL of the RRSIG RR and each RR in the authenticated RRset to   
 1687    a value no greater than the minimum of:                                 
 1688                                                                            
 1689    o  the RRset's TTL as received in the response;                         
 1690                                                                            
 1691    o  the RRSIG RR's TTL as received in the response;                      
 1692                                                                            
 1693    o  the value in the RRSIG RR's Original TTL field; and                  
 1694                                                                            
 1695    o  the difference of the RRSIG RR's Signature Expiration time and the   
 1696       current time.                                                        
 1697                                                                            
 1698                                                                            
 1699                                                                            
 1700                                                                            
 1701                                                                            
 1702 Arends, et al.              Standards Track                    [Page 31]   

 1703 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1704                                                                            
 1705                                                                            
 1706 5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response         
 1707                                                                            
 1708    If the number of labels in an RRset's owner name is greater than the    
 1709    Labels field of the covering RRSIG RR, then the RRset and its           
 1710    covering RRSIG RR were created as a result of wildcard expansion.       
 1711    Once the validator has verified the signature, as described in          
 1712    Section 5.3, it must take additional steps to verify the non-           
 1713    existence of an exact match or closer wildcard match for the query.     
 1714    Section 5.4 discusses these steps.                                      
 1715                                                                            
 1716    Note that the response received by the resolver should include all      
 1717    NSEC RRs needed to authenticate the response (see Section 3.1.3).       
 1718                                                                            

Section 5.4 of RFC6840 says:

When multiple RRSIGs cover a given RRset, Section 5.3.3 of [RFC4035]
suggests that "the local resolver security policy determines whether
the resolver also has to test these RRSIG RRs and how to resolve
conflicts if these RRSIG RRs lead to differing results".

This document specifies that a resolver SHOULD accept any valid RRSIG
as sufficient, and only determine that an RRset is Bogus if all
RRSIGs fail validation.

If a resolver adopts a more restrictive policy, there's a danger that
properly signed data might unnecessarily fail validation due to cache
timing issues.  Furthermore, certain zone management techniques, like
the Double Signature Zone Signing Key Rollover method described in
Section 4.2.1.2 of [RFC6781], will not work reliably.  Such a
resolver is also vulnerable to malicious insertion of gibberish
signatures.

 1719 5.4.  Authenticated Denial of Existence                                    
 1720                                                                            
 1721    A resolver can use authenticated NSEC RRs to prove that an RRset is     
 1722    not present in a signed zone.  Security-aware name servers should       
 1723    automatically include any necessary NSEC RRs for signed zones in        
 1724    their responses to security-aware resolvers.                            
 1725                                                                            
 1726    Denial of existence is determined by the following rules:               
 1727                                                                            
 1728    o  If the requested RR name matches the owner name of an                
 1729       authenticated NSEC RR, then the NSEC RR's type bit map field lists   
 1730       all RR types present at that owner name, and a resolver can prove    
 1731       that the requested RR type does not exist by checking for the RR     
 1732       type in the bit map.  If the number of labels in an authenticated    
 1733       NSEC RR's owner name equals the Labels field of the covering RRSIG   
 1734       RR, then the existence of the NSEC RR proves that wildcard           
 1735       expansion could not have been used to match the request.             
 1736                                                                            
 1737    o  If the requested RR name would appear after an authenticated NSEC    
 1738       RR's owner name and before the name listed in that NSEC RR's Next    
 1739       Domain Name field according to the canonical DNS name order          
 1740       defined in [RFC4034], then no RRsets with the requested name exist   
 1741       in the zone.  However, it is possible that a wildcard could be       
 1742       used to match the requested RR owner name and type, so proving       
 1743       that the requested RRset does not exist also requires proving that   
 1744       no possible wildcard RRset exists that could have been used to       
 1745       generate a positive response.                                        
 1746                                                                            
 1747    In addition, security-aware resolvers MUST authenticate the NSEC        
 1748    RRsets that comprise the non-existence proof as described in Section    
 1749    5.3.                                                                    
 1750                                                                            
 1751    To prove the non-existence of an RRset, the resolver must be able to    
 1752    verify both that the queried RRset does not exist and that no           
 1753    relevant wildcard RRset exists.  Proving this may require more than     
 1754                                                                            
 1755                                                                            
 1756                                                                            
 1757 Arends, et al.              Standards Track                    [Page 32]   

 1758 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1759                                                                            
 1760                                                                            
 1761    one NSEC RRset from the zone.  If the complete set of necessary NSEC    
 1762    RRsets is not present in a response (perhaps due to message             
 1763    truncation), then a security-aware resolver MUST resend the query in    
 1764    order to attempt to obtain the full collection of NSEC RRs necessary    
 1765    to verify the non-existence of the requested RRset.  As with all DNS    
 1766    operations, however, the resolver MUST bound the work it puts into      
 1767    answering any particular query.                                         
 1768                                                                            
 1769    Since a validated NSEC RR proves the existence of both itself and its   
 1770    corresponding RRSIG RR, a validator MUST ignore the settings of the     
 1771    NSEC and RRSIG bits in an NSEC RR.                                      
 1772                                                                            
 1773 5.5.  Resolver Behavior When Signatures Do Not Validate                    
 1774                                                                            
 1775    If for whatever reason none of the RRSIGs can be validated, the         
 1776    response SHOULD be considered BAD.  If the validation was being done    
 1777    to service a recursive query, the name server MUST return RCODE 2 to    
 1778    the originating client.  However, it MUST return the full response if   
 1779    and only if the original query had the CD bit set.  Also see Section    
 1780    4.7 on caching responses that do not validate.                          
 1781                                                                            
 1782 5.6.  Authentication Example                                               
 1783                                                                            
 1784    Appendix C shows an example of the authentication process.              
 1785                                                                            
 1786 6.  IANA Considerations                                                    
 1787                                                                            
 1788    [RFC4034] contains a review of the IANA considerations introduced by    
 1789    DNSSEC.  The following are additional IANA considerations discussed     
 1790    in this document:                                                       
 1791                                                                            
 1792    [RFC2535] reserved the CD and AD bits in the message header.  The       
 1793    meaning of the AD bit was redefined in [RFC3655], and the meaning of    
 1794    both the CD and AD bit are restated in this document.  No new bits in   
 1795    the DNS message header are defined in this document.                    
 1796                                                                            
 1797    [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit     
 1798    and defined its use.  The use is restated but not altered in this       
 1799    document.                                                               
 1800                                                                            
 1801 7.  Security Considerations                                                
 1802                                                                            
 1803    This document describes how the DNS security extensions use public      
 1804    key cryptography to sign and authenticate DNS resource record sets.     
 1805    Please see [RFC4033] for terminology and general security               
 1806    considerations related to DNSSEC; see [RFC4034] for considerations      
 1807    specific to the DNSSEC resource record types.                           
 1808                                                                            
 1809                                                                            
 1810                                                                            
 1811                                                                            
 1812 Arends, et al.              Standards Track                    [Page 33]   

 1813 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1814                                                                            
 1815                                                                            
 1816    An active attacker who can set the CD bit in a DNS query message or     
 1817    the AD bit in a DNS response message can use these bits to defeat the   
 1818    protection that DNSSEC attempts to provide to security-oblivious        
 1819    recursive-mode resolvers.  For this reason, use of these control bits   
 1820    by a security-aware recursive-mode resolver requires a secure           
 1821    channel.  See Sections 3.2.2 and 4.9 for further discussion.            
 1822                                                                            
 1823    The protocol described in this document attempts to extend the          
 1824    benefits of DNSSEC to security-oblivious stub resolvers.  However, as   
 1825    recovery from validation failures is likely to be specific to           
 1826    particular applications, the facilities that DNSSEC provides for stub   
 1827    resolvers may prove inadequate.  Operators of security-aware            
 1828    recursive name servers will have to pay close attention to the          
 1829    behavior of the applications that use their services when choosing a    
 1830    local validation policy; failure to do so could easily result in the    
 1831    recursive name server accidentally denying service to the clients it    
 1832    is intended to support.                                                 
 1833                                                                            
 1834 8.  Acknowledgements                                                       
 1835                                                                            
 1836    This document was created from the input and ideas of the members of    
 1837    the DNS Extensions Working Group and working group mailing list.  The   
 1838    editors would like to express their thanks for the comments and         
 1839    suggestions received during the revision of these security extension    
 1840    specifications.  Although explicitly listing everyone who has           
 1841    contributed during the decade in which DNSSEC has been under            
 1842    development would be impossible, [RFC4033] includes a list of some of   
 1843    the participants who were kind enough to comment on these documents.    
 1844                                                                            
 1845 9.  References                                                             
 1846                                                                            
 1847 9.1.  Normative References                                                 
 1848                                                                            
 1849    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
 1850               STD 13, RFC 1034, November 1987.                             
 1851                                                                            
 1852    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
 1853               specification", STD 13, RFC 1035, November 1987.             
 1854                                                                            
 1855    [RFC1122]  Braden, R., "Requirements for Internet Hosts -               
 1856               Communication Layers", STD 3, RFC 1122, October 1989.        
 1857                                                                            
 1858    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
 1859               Requirement Levels", BCP 14, RFC 2119, March 1997.           
 1860                                                                            
 1861    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
 1862               Specification", RFC 2181, July 1997.                         
 1863                                                                            
 1864                                                                            
 1865                                                                            
 1866                                                                            
 1867 Arends, et al.              Standards Track                    [Page 34]   

 1868 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1869                                                                            
 1870                                                                            
 1871    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6     
 1872               (IPv6) Specification", RFC 2460, December 1998.              
 1873                                                                            
 1874    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC       
 1875               2671, August 1999.                                           
 1876                                                                            
 1877    [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC       
 1878               2672, August 1999.                                           
 1879                                                                            
 1880    [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC     
 1881               3225, December 2001.                                         
 1882                                                                            
 1883    [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver   
 1884               message size requirements", RFC 3226, December 2001.         
 1885                                                                            
 1886    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1887               Rose, "DNS Security Introduction and Requirements", RFC      
 1888               4033, March 2005.                                            
 1889                                                                            
 1890    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
 1891               Rose, "Resource Records for DNS Security Extensions", RFC    
 1892               4034, March 2005.                                            
 1893                                                                            
 1894 9.2.  Informative References                                               
 1895                                                                            
 1896    [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS           
 1897               NCACHE)", RFC 2308, March 1998.                              
 1898                                                                            
 1899    [RFC2535]  Eastlake 3rd, D., "Domain Name System Security               
 1900               Extensions", RFC 2535, March 1999.                           
 1901                                                                            
 1902    [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic     
 1903               Update", RFC 3007, November 2000.                            
 1904                                                                            
 1905    [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS      
 1906               Authenticated Data (AD) bit", RFC 3655, November 2003.       
 1907                                                                            
 1908                                                                            
 1909                                                                            
 1910                                                                            
 1911                                                                            
 1912                                                                            
 1913                                                                            
 1914                                                                            
 1915                                                                            
 1916                                                                            
 1917                                                                            
 1918                                                                            
 1919                                                                            
 1920                                                                            
 1921                                                                            
 1922 Arends, et al.              Standards Track                    [Page 35]   

 1923 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1924                                                                            
 1925                                                                            
 1926 Appendix A.  Signed Zone Example                                           
 1927                                                                            
 1928    The following example shows a (small) complete signed zone.             
 1929                                                                            
 1930    example.       3600 IN SOA ns1.example. bugs.x.w.example. (             
 1931                               1081539377                                   
 1932                               3600                                         
 1933                               300                                          
 1934                               3600000                                      
 1935                               3600                                         
 1936                               )                                            
 1937                   3600 RRSIG  SOA 5 1 3600 20040509183619 (                
 1938                               20040409183619 38519 example.                
 1939                               ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h         
 1940                               7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF         
 1941                               vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW         
 1942                               DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB         
 1943                               jV7j86HyQgM5e7+miRAz8V01b0I= )               
 1944                   3600 NS     ns1.example.                                 
 1945                   3600 NS     ns2.example.                                 
 1946                   3600 RRSIG  NS 5 1 3600 20040509183619 (                 
 1947                               20040409183619 38519 example.                
 1948                               gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd         
 1949                               EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf         
 1950                               4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8         
 1951                               RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48         
 1952                               0HjMeRaZB/FRPGfJPajngcq6Kwg= )               
 1953                   3600 MX     1 xx.example.                                
 1954                   3600 RRSIG  MX 5 1 3600 20040509183619 (                 
 1955                               20040409183619 38519 example.                
 1956                               HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB         
 1957                               2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE         
 1958                               VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO         
 1959                               6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM         
 1960                               W6OISukd1EQt7a0kygkg+PEDxdI= )               
 1961                   3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY       
 1962                   3600 RRSIG  NSEC 5 1 3600 20040509183619 (               
 1963                               20040409183619 38519 example.                
 1964                               O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm         
 1965                               FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V         
 1966                               Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW         
 1967                               SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm         
 1968                               jfFJ5arXf4nPxp/kEowGgBRzY/U= )               
 1969                   3600 DNSKEY 256 3 5 (                                    
 1970                               AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV         
 1971                               rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e         
 1972                               k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo         
 1973                               vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI         
 1974                                                                            
 1975                                                                            
 1976                                                                            
 1977 Arends, et al.              Standards Track                    [Page 36]   

 1978 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 1979                                                                            
 1980                                                                            
 1981                               ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==             
 1982                               )                                            
 1983                   3600 DNSKEY 257 3 5 (                                    
 1984                               AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl         
 1985                               LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ         
 1986                               syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP         
 1987                               RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT         
 1988                               Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==             
 1989                               )                                            
 1990                   3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (             
 1991                               20040409183619 9465 example.                 
 1992                               ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ         
 1993                               xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ         
 1994                               XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9         
 1995                               hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY         
 1996                               NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )               
 1997                   3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (             
 1998                               20040409183619 38519 example.                
 1999                               eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z         
 2000                               DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri         
 2001                               bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp         
 2002                               eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk         
 2003                               7z5OXogYVaFzHKillDt3HRxHIZM= )               
 2004    a.example.     3600 IN NS  ns1.a.example.                               
 2005                   3600 IN NS  ns2.a.example.                               
 2006                   3600 DS     57855 5 1 (                                  
 2007                               B6DCD485719ADCA18E5F3D48A2331627FDD3         
 2008                               636B )                                       
 2009                   3600 RRSIG  DS 5 2 3600 20040509183619 (                 
 2010                               20040409183619 38519 example.                
 2011                               oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ         
 2012                               oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH         
 2013                               kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD         
 2014                               EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/         
 2015                               Fm+v6ccF2EGNLRiY08kdkz+XHHo= )               
 2016                   3600 NSEC   ai.example. NS DS RRSIG NSEC                 
 2017                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2018                               20040409183619 38519 example.                
 2019                               cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba         
 2020                               U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2         
 2021                               039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I         
 2022                               BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g         
 2023                               sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )               
 2024    ns1.a.example. 3600 IN A   192.0.2.5                                    
 2025    ns2.a.example. 3600 IN A   192.0.2.6                                    
 2026    ai.example.    3600 IN A   192.0.2.9                                    
 2027                   3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2028                               20040409183619 38519 example.                
 2029                                                                            
 2030                                                                            
 2031                                                                            
 2032 Arends, et al.              Standards Track                    [Page 37]   

 2033 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2034                                                                            
 2035                                                                            
 2036                               pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B         
 2037                               ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd         
 2038                               hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u         
 2039                               ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy         
 2040                               6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )               
 2041                   3600 HINFO  "KLH-10" "ITS"                               
 2042                   3600 RRSIG  HINFO 5 2 3600 20040509183619 (              
 2043                               20040409183619 38519 example.                
 2044                               Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l         
 2045                               e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh         
 2046                               ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7         
 2047                               AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw         
 2048                               FvL8sqlS5QS6FY/ijFEDnI4RkZA= )               
 2049                   3600 AAAA   2001:db8::f00:baa9                           
 2050                   3600 RRSIG  AAAA 5 2 3600 20040509183619 (               
 2051                               20040409183619 38519 example.                
 2052                               nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK         
 2053                               kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh         
 2054                               1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T         
 2055                               cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2         
 2056                               sZM6QjBBLmukH30+w1z3h8PUP2o= )               
 2057                   3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC           
 2058                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2059                               20040409183619 38519 example.                
 2060                               QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG         
 2061                               CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p         
 2062                               P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN         
 2063                               3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL         
 2064                               AhS+JOVfDI/79QtyTI0SaDWcg8U= )               
 2065    b.example.     3600 IN NS  ns1.b.example.                               
 2066                   3600 IN NS  ns2.b.example.                               
 2067                   3600 NSEC   ns1.example. NS RRSIG NSEC                   
 2068                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2069                               20040409183619 38519 example.                
 2070                               GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx         
 2071                               9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS         
 2072                               xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs         
 2073                               0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ         
 2074                               vhRXgWT7OuFXldoCG6TfVFMs9xE= )               
 2075    ns1.b.example. 3600 IN A   192.0.2.7                                    
 2076    ns2.b.example. 3600 IN A   192.0.2.8                                    
 2077    ns1.example.   3600 IN A   192.0.2.1                                    
 2078                   3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2079                               20040409183619 38519 example.                
 2080                               F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet         
 2081                               5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06         
 2082                               im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+         
 2083                               +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK         
 2084                                                                            
 2085                                                                            
 2086                                                                            
 2087 Arends, et al.              Standards Track                    [Page 38]   

 2088 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2089                                                                            
 2090                                                                            
 2091                               v/iVXSYC0b7mPSU+EOlknFpVECs= )               
 2092                   3600 NSEC   ns2.example. A RRSIG NSEC                    
 2093                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2094                               20040409183619 38519 example.                
 2095                               I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8         
 2096                               1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB         
 2097                               jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq         
 2098                               ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8         
 2099                               IZaIGBLryQWGLw6Y6X8dqhlnxJM= )               
 2100    ns2.example.   3600 IN A   192.0.2.2                                    
 2101                   3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2102                               20040409183619 38519 example.                
 2103                               V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq         
 2104                               Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu         
 2105                               yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO         
 2106                               6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq         
 2107                               rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )               
 2108                   3600 NSEC   *.w.example. A RRSIG NSEC                    
 2109                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2110                               20040409183619 38519 example.                
 2111                               N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE         
 2112                               VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb         
 2113                               3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH         
 2114                               l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw         
 2115                               Ymx28EtgIpo9A0qmP08rMBqs1Jw= )               
 2116    *.w.example.   3600 IN MX  1 ai.example.                                
 2117                   3600 RRSIG  MX 5 2 3600 20040509183619 (                 
 2118                               20040409183619 38519 example.                
 2119                               OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2         
 2120                               f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc         
 2121                               tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X         
 2122                               TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw         
 2123                               4kX18MMR34i8lC36SR5xBni8vHI= )               
 2124                   3600 NSEC   x.w.example. MX RRSIG NSEC                   
 2125                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2126                               20040409183619 38519 example.                
 2127                               r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9         
 2128                               HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU         
 2129                               5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx         
 2130                               91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8         
 2131                               s1InQ2UoIv6tJEaaKkP701j8OLA= )               
 2132    x.w.example.   3600 IN MX  1 xx.example.                                
 2133                   3600 RRSIG  MX 5 3 3600 20040509183619 (                 
 2134                               20040409183619 38519 example.                
 2135                               Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1         
 2136                               XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP         
 2137                               H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I         
 2138                               kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1         
 2139                                                                            
 2140                                                                            
 2141                                                                            
 2142 Arends, et al.              Standards Track                    [Page 39]   

 2143 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2144                                                                            
 2145                                                                            
 2146                               jNSlwZ2mSWKHfxFQxPtLj8s32+k= )               
 2147                   3600 NSEC   x.y.w.example. MX RRSIG NSEC                 
 2148                   3600 RRSIG  NSEC 5 3 3600 20040509183619 (               
 2149                               20040409183619 38519 example.                
 2150                               aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK         
 2151                               vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E         
 2152                               mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI         
 2153                               NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e         
 2154                               IjgiM8PXkBQtxPq37wDKALkyn7Q= )               
 2155    x.y.w.example. 3600 IN MX  1 xx.example.                                
 2156                   3600 RRSIG  MX 5 4 3600 20040509183619 (                 
 2157                               20040409183619 38519 example.                
 2158                               k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia         
 2159                               t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj         
 2160                               q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq         
 2161                               GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb         
 2162                               +gLcMZBnHJ326nb/TOOmrqNmQQE= )               
 2163                   3600 NSEC   xx.example. MX RRSIG NSEC                    
 2164                   3600 RRSIG  NSEC 5 4 3600 20040509183619 (               
 2165                               20040409183619 38519 example.                
 2166                               OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp         
 2167                               ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg         
 2168                               xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX         
 2169                               a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr         
 2170                               QoKqJDCLnoAlcPOPKAm/jJkn3jk= )               
 2171    xx.example.    3600 IN A   192.0.2.10                                   
 2172                   3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2173                               20040409183619 38519 example.                
 2174                               kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP         
 2175                               7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa         
 2176                               0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y         
 2177                               VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx         
 2178                               kbIDV6GPPSZVusnZU6OMgdgzHV4= )               
 2179                   3600 HINFO  "KLH-10" "TOPS-20"                           
 2180                   3600 RRSIG  HINFO 5 2 3600 20040509183619 (              
 2181                               20040409183619 38519 example.                
 2182                               GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0         
 2183                               t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq         
 2184                               BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8         
 2185                               3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+         
 2186                               RgNvuwbioFSEuv2pNlkq0goYxNY= )               
 2187                   3600 AAAA   2001:db8::f00:baaa                           
 2188                   3600 RRSIG  AAAA 5 2 3600 20040509183619 (               
 2189                               20040409183619 38519 example.                
 2190                               Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C         
 2191                               aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z         
 2192                               ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr         
 2193                               U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/         
 2194                                                                            
 2195                                                                            
 2196                                                                            
 2197 Arends, et al.              Standards Track                    [Page 40]   

 2198 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2199                                                                            
 2200                                                                            
 2201                               xS9cL2QgW7FChw16mzlkH6/vsfs= )               
 2202                   3600 NSEC   example. A HINFO AAAA RRSIG NSEC             
 2203                   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2204                               20040409183619 38519 example.                
 2205                               ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY         
 2206                               9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k         
 2207                               mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi         
 2208                               asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W         
 2209                               GghLahumFIpg4MO3LS/prgzVVWo= )               
 2210                                                                            
 2211    The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA       
 2212    Flags indicate that each of these DNSKEY RRs is a zone key.  One of     
 2213    these DNSKEY RRs also has the SEP flag set and has been used to sign    
 2214    the apex DNSKEY RRset; this is the key that should be hashed to         
 2215    generate a DS record to be inserted into the parent zone.  The other    
 2216    DNSKEY is used to sign all the other RRsets in the zone.                
 2217                                                                            
 2218    The zone includes a wildcard entry, "*.w.example".  Note that the       
 2219    name "*.w.example" is used in constructing NSEC chains, and that the    
 2220    RRSIG covering the "*.w.example" MX RRset has a label count of 2.       
 2221                                                                            
 2222    The zone also includes two delegations.  The delegation to              
 2223    "b.example" includes an NS RRset, glue address records, and an NSEC     
 2224    RR; note that only the NSEC RRset is signed.  The delegation to         
 2225    "a.example" provides a DS RR; note that only the NSEC and DS RRsets     
 2226    are signed.                                                             
 2227                                                                            
 2228 Appendix B.  Example Responses                                             
 2229                                                                            
 2230    The examples in this section show response messages using the signed    
 2231    zone example in Appendix A.                                             
 2232                                                                            
 2233 B.1.  Answer                                                               
 2234                                                                            
 2235    A successful query to an authoritative server.                          
 2236                                                                            
 2237    ;; Header: QR AA DO RCODE=0                                             
 2238    ;;                                                                      
 2239    ;; Question                                                             
 2240    x.w.example.        IN MX                                               
 2241                                                                            
 2242    ;; Answer                                                               
 2243    x.w.example.   3600 IN MX  1 xx.example.                                
 2244    x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (                 
 2245                               20040409183619 38519 example.                
 2246                               Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1         
 2247                               XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP         
 2248                               H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I         
 2249                                                                            
 2250                                                                            
 2251                                                                            
 2252 Arends, et al.              Standards Track                    [Page 41]   

 2253 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2254                                                                            
 2255                                                                            
 2256                               kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1         
 2257                               jNSlwZ2mSWKHfxFQxPtLj8s32+k= )               
 2258                                                                            
 2259    ;; Authority                                                            
 2260    example.       3600 NS     ns1.example.                                 
 2261    example.       3600 NS     ns2.example.                                 
 2262    example.       3600 RRSIG  NS 5 1 3600 20040509183619 (                 
 2263                               20040409183619 38519 example.                
 2264                               gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd         
 2265                               EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf         
 2266                               4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8         
 2267                               RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48         
 2268                               0HjMeRaZB/FRPGfJPajngcq6Kwg= )               
 2269                                                                            
 2270    ;; Additional                                                           
 2271    xx.example.    3600 IN A   192.0.2.10                                   
 2272    xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2273                               20040409183619 38519 example.                
 2274                               kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP         
 2275                               7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa         
 2276                               0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y         
 2277                               VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx         
 2278                               kbIDV6GPPSZVusnZU6OMgdgzHV4= )               
 2279    xx.example.    3600 AAAA   2001:db8::f00:baaa                           
 2280    xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (               
 2281                               20040409183619 38519 example.                
 2282                               Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C         
 2283                               aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z         
 2284                               ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr         
 2285                               U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/         
 2286                               xS9cL2QgW7FChw16mzlkH6/vsfs= )               
 2287    ns1.example.   3600 IN A   192.0.2.1                                    
 2288    ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2289                               20040409183619 38519 example.                
 2290                               F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet         
 2291                               5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06         
 2292                               im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+         
 2293                               +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK         
 2294                               v/iVXSYC0b7mPSU+EOlknFpVECs= )               
 2295    ns2.example.   3600 IN A   192.0.2.2                                    
 2296    ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2297                               20040409183619 38519 example.                
 2298                               V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq         
 2299                               Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu         
 2300                               yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO         
 2301                               6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq         
 2302                               rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )               
 2303                                                                            
 2304                                                                            
 2305                                                                            
 2306                                                                            
 2307 Arends, et al.              Standards Track                    [Page 42]   

 2308 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2309                                                                            
 2310                                                                            
 2311 B.2.  Name Error                                                           
 2312                                                                            
 2313    An authoritative name error.  The NSEC RRs prove that the name does     
 2314    not exist and that no covering wildcard exists.                         
 2315                                                                            
 2316    ;; Header: QR AA DO RCODE=3                                             
 2317    ;;                                                                      
 2318    ;; Question                                                             
 2319    ml.example.         IN A                                                
 2320                                                                            
 2321    ;; Answer                                                               
 2322    ;; (empty)                                                              
 2323                                                                            
 2324    ;; Authority                                                            
 2325    example.       3600 IN SOA ns1.example. bugs.x.w.example. (             
 2326                               1081539377                                   
 2327                               3600                                         
 2328                               300                                          
 2329                               3600000                                      
 2330                               3600                                         
 2331                               )                                            
 2332    example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (                
 2333                               20040409183619 38519 example.                
 2334                               ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h         
 2335                               7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF         
 2336                               vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW         
 2337                               DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB         
 2338                               jV7j86HyQgM5e7+miRAz8V01b0I= )               
 2339    b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC                   
 2340    b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2341                               20040409183619 38519 example.                
 2342                               GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx         
 2343                               9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS         
 2344                               xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs         
 2345                               0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ         
 2346                               vhRXgWT7OuFXldoCG6TfVFMs9xE= )               
 2347    example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY       
 2348    example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (               
 2349                               20040409183619 38519 example.                
 2350                               O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm         
 2351                               FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V         
 2352                               Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW         
 2353                               SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm         
 2354                               jfFJ5arXf4nPxp/kEowGgBRzY/U= )               
 2355                                                                            
 2356    ;; Additional                                                           
 2357    ;; (empty)                                                              
 2358                                                                            
 2359                                                                            
 2360                                                                            
 2361                                                                            
 2362 Arends, et al.              Standards Track                    [Page 43]   

 2363 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2364                                                                            
 2365                                                                            
 2366 B.3.  No Data Error                                                        
 2367                                                                            
 2368    A "no data" response.  The NSEC RR proves that the name exists and      
 2369    that the requested RR type does not.                                    
 2370                                                                            
 2371    ;; Header: QR AA DO RCODE=0                                             
 2372    ;;                                                                      
 2373    ;; Question                                                             
 2374    ns1.example.        IN MX                                               
 2375                                                                            
 2376    ;; Answer                                                               
 2377    ;; (empty)                                                              
 2378                                                                            
 2379    ;; Authority                                                            
 2380    example.       3600 IN SOA ns1.example. bugs.x.w.example. (             
 2381                               1081539377                                   
 2382                               3600                                         
 2383                               300                                          
 2384                               3600000                                      
 2385                               3600                                         
 2386                               )                                            
 2387    example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (                
 2388                               20040409183619 38519 example.                
 2389                               ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h         
 2390                               7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF         
 2391                               vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW         
 2392                               DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB         
 2393                               jV7j86HyQgM5e7+miRAz8V01b0I= )               
 2394    ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC                    
 2395    ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2396                               20040409183619 38519 example.                
 2397                               I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8         
 2398                               1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB         
 2399                               jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq         
 2400                               ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8         
 2401                               IZaIGBLryQWGLw6Y6X8dqhlnxJM= )               
 2402                                                                            
 2403    ;; Additional                                                           
 2404    ;; (empty)                                                              
 2405                                                                            
 2406 B.4.  Referral to Signed Zone                                              
 2407                                                                            
 2408    Referral to a signed zone.  The DS RR contains the data which the       
 2409    resolver will need to validate the corresponding DNSKEY RR in the       
 2410    child zone's apex.                                                      
 2411                                                                            
 2412    ;; Header: QR DO RCODE=0                                                
 2413    ;;                                                                      
 2414                                                                            
 2415                                                                            
 2416                                                                            
 2417 Arends, et al.              Standards Track                    [Page 44]   

 2418 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2419                                                                            
 2420                                                                            
 2421    ;; Question                                                             
 2422    mc.a.example.       IN MX                                               
 2423                                                                            
 2424    ;; Answer                                                               
 2425    ;; (empty)                                                              
 2426                                                                            
 2427    ;; Authority                                                            
 2428    a.example.     3600 IN NS  ns1.a.example.                               
 2429    a.example.     3600 IN NS  ns2.a.example.                               
 2430    a.example.     3600 DS     57855 5 1 (                                  
 2431                               B6DCD485719ADCA18E5F3D48A2331627FDD3         
 2432                               636B )                                       
 2433    a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (                 
 2434                               20040409183619 38519 example.                
 2435                               oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ         
 2436                               oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH         
 2437                               kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD         
 2438                               EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/         
 2439                               Fm+v6ccF2EGNLRiY08kdkz+XHHo= )               
 2440                                                                            
 2441    ;; Additional                                                           
 2442    ns1.a.example. 3600 IN A   192.0.2.5                                    
 2443    ns2.a.example. 3600 IN A   192.0.2.6                                    
 2444                                                                            
 2445 B.5.  Referral to Unsigned Zone                                            
 2446                                                                            
 2447    Referral to an unsigned zone.  The NSEC RR proves that no DS RR for     
 2448    this delegation exists in the parent zone.                              
 2449                                                                            
 2450    ;; Header: QR DO RCODE=0                                                
 2451    ;;                                                                      
 2452    ;; Question                                                             
 2453    mc.b.example.       IN MX                                               
 2454                                                                            
 2455    ;; Answer                                                               
 2456    ;; (empty)                                                              
 2457                                                                            
 2458    ;; Authority                                                            
 2459    b.example.     3600 IN NS  ns1.b.example.                               
 2460    b.example.     3600 IN NS  ns2.b.example.                               
 2461    b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC                   
 2462    b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2463                               20040409183619 38519 example.                
 2464                               GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx         
 2465                               9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS         
 2466                               xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs         
 2467                               0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ         
 2468                               vhRXgWT7OuFXldoCG6TfVFMs9xE= )               
 2469                                                                            
 2470                                                                            
 2471                                                                            
 2472 Arends, et al.              Standards Track                    [Page 45]   

 2473 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2474                                                                            
 2475                                                                            
 2476    ;; Additional                                                           
 2477    ns1.b.example. 3600 IN A   192.0.2.7                                    
 2478    ns2.b.example. 3600 IN A   192.0.2.8                                    
 2479                                                                            
 2480 B.6.  Wildcard Expansion                                                   
 2481                                                                            
 2482    A successful query that was answered via wildcard expansion.  The       
 2483    label count in the answer's RRSIG RR indicates that a wildcard RRset    
 2484    was expanded to produce this response, and the NSEC RR proves that no   
 2485    closer match exists in the zone.                                        
 2486                                                                            
 2487    ;; Header: QR AA DO RCODE=0                                             
 2488    ;;                                                                      
 2489    ;; Question                                                             
 2490    a.z.w.example.      IN MX                                               
 2491                                                                            
 2492    ;; Answer                                                               
 2493    a.z.w.example. 3600 IN MX  1 ai.example.                                
 2494    a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (                 
 2495                               20040409183619 38519 example.                
 2496                               OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2         
 2497                               f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc         
 2498                               tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X         
 2499                               TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw         
 2500                               4kX18MMR34i8lC36SR5xBni8vHI= )               
 2501                                                                            
 2502    ;; Authority                                                            
 2503    example.       3600 NS     ns1.example.                                 
 2504    example.       3600 NS     ns2.example.                                 
 2505    example.       3600 RRSIG  NS 5 1 3600 20040509183619 (                 
 2506                               20040409183619 38519 example.                
 2507                               gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd         
 2508                               EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf         
 2509                               4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8         
 2510                               RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48         
 2511                               0HjMeRaZB/FRPGfJPajngcq6Kwg= )               
 2512    x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC                    
 2513    x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (               
 2514                               20040409183619 38519 example.                
 2515                               OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp         
 2516                               ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg         
 2517                               xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX         
 2518                               a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr         
 2519                               QoKqJDCLnoAlcPOPKAm/jJkn3jk= )               
 2520                                                                            
 2521    ;; Additional                                                           
 2522    ai.example.    3600 IN A   192.0.2.9                                    
 2523    ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (                  
 2524                                                                            
 2525                                                                            
 2526                                                                            
 2527 Arends, et al.              Standards Track                    [Page 46]   

 2528 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2529                                                                            
 2530                                                                            
 2531                               20040409183619 38519 example.                
 2532                               pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B         
 2533                               ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd         
 2534                               hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u         
 2535                               ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy         
 2536                               6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )               
 2537    ai.example.    3600 AAAA   2001:db8::f00:baa9                           
 2538    ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (               
 2539                               20040409183619 38519 example.                
 2540                               nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK         
 2541                               kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh         
 2542                               1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T         
 2543                               cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2         
 2544                               sZM6QjBBLmukH30+w1z3h8PUP2o= )               
 2545                                                                            
 2546 B.7.  Wildcard No Data Error                                               
 2547                                                                            
 2548    A "no data" response for a name covered by a wildcard.  The NSEC RRs    
 2549    prove that the matching wildcard name does not have any RRs of the      
 2550    requested type and that no closer match exists in the zone.             
 2551                                                                            
 2552    ;; Header: QR AA DO RCODE=0                                             
 2553    ;;                                                                      
 2554    ;; Question                                                             
 2555    a.z.w.example.      IN AAAA                                             
 2556                                                                            
 2557    ;; Answer                                                               
 2558    ;; (empty)                                                              
 2559                                                                            
 2560    ;; Authority                                                            
 2561    example.       3600 IN SOA ns1.example. bugs.x.w.example. (             
 2562                               1081539377                                   
 2563                               3600                                         
 2564                               300                                          
 2565                               3600000                                      
 2566                               3600                                         
 2567                               )                                            
 2568    example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (                
 2569                               20040409183619 38519 example.                
 2570                               ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h         
 2571                               7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF         
 2572                               vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW         
 2573                               DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB         
 2574                               jV7j86HyQgM5e7+miRAz8V01b0I= )               
 2575    x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC                    
 2576    x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (               
 2577                               20040409183619 38519 example.                
 2578                               OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp         
 2579                                                                            
 2580                                                                            
 2581                                                                            
 2582 Arends, et al.              Standards Track                    [Page 47]   

 2583 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2584                                                                            
 2585                                                                            
 2586                               ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg         
 2587                               xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX         
 2588                               a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr         
 2589                               QoKqJDCLnoAlcPOPKAm/jJkn3jk= )               
 2590    *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC                   
 2591    *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (               
 2592                               20040409183619 38519 example.                
 2593                               r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9         
 2594                               HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU         
 2595                               5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx         
 2596                               91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8         
 2597                               s1InQ2UoIv6tJEaaKkP701j8OLA= )               
 2598                                                                            
 2599    ;; Additional                                                           
 2600    ;; (empty)                                                              
 2601                                                                            
 2602 B.8.  DS Child Zone No Data Error                                          
 2603                                                                            
 2604    A "no data" response for a QTYPE=DS query that was mistakenly sent to   
 2605    a name server for the child zone.                                       
 2606                                                                            
 2607    ;; Header: QR AA DO RCODE=0                                             
 2608    ;;                                                                      
 2609    ;; Question                                                             
 2610    example.            IN DS                                               
 2611                                                                            
 2612    ;; Answer                                                               
 2613    ;; (empty)                                                              
 2614                                                                            
 2615    ;; Authority                                                            
 2616    example.       3600 IN SOA ns1.example. bugs.x.w.example. (             
 2617                               1081539377                                   
 2618                               3600                                         
 2619                               300                                          
 2620                               3600000                                      
 2621                               3600                                         
 2622                               )                                            
 2623    example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (                
 2624                               20040409183619 38519 example.                
 2625                               ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h         
 2626                               7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF         
 2627                               vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW         
 2628                               DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB         
 2629                               jV7j86HyQgM5e7+miRAz8V01b0I= )               
 2630    example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY       
 2631    example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (               
 2632                               20040409183619 38519 example.                
 2633                               O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm         
 2634                                                                            
 2635                                                                            
 2636                                                                            
 2637 Arends, et al.              Standards Track                    [Page 48]   

 2638 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2639                                                                            
 2640                                                                            
 2641                               FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V         
 2642                               Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW         
 2643                               SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm         
 2644                               jfFJ5arXf4nPxp/kEowGgBRzY/U= )               
 2645                                                                            
 2646    ;; Additional                                                           
 2647    ;; (empty)                                                              
 2648                                                                            
 2649 Appendix C.  Authentication Examples                                       
 2650                                                                            
 2651    The examples in this section show how the response messages in          
 2652    Appendix B are authenticated.                                           
 2653                                                                            

Section 4.1 of RFC6840 says:

Section 5.4 of [RFC4035] under-specifies the algorithm for checking
nonexistence proofs.  In particular, the algorithm as presented would
allow a validator to interpret an NSEC or NSEC3 RR from an ancestor
zone as proving the nonexistence of an RR in a child zone.

An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:

o  the NS bit set,

o  the Start of Authority (SOA) bit clear, and 

o  a signer field that is shorter than the owner name of the NSEC RR,
	 or the original owner name for the NSEC3 RR.

Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume
nonexistence of any RRs below that zone cut, which include all RRs at
that (original) owner name other than DS RRs, and all RRs below that
owner name regardless of type.

Similarly, the algorithm would also allow an NSEC RR at the same
owner name as a DNAME RR, or an NSEC3 RR at the same original owner
name as a DNAME, to prove the nonexistence of names beneath that
DNAME.  An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
to assume the nonexistence of any subdomain of that NSEC/NSEC3 RR's
(original) owner name.

 2654 C.1.  Authenticating an Answer                                             
 2655                                                                            
 2656    The query in Appendix B.1 returned an MX RRset for "x.w.example.com".   
 2657    The corresponding RRSIG indicates that the MX RRset was signed by an    
 2658    "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver      
 2659    needs the corresponding DNSKEY RR in order to authenticate this         
 2660    answer.  The discussion below describes how a resolver might obtain     
 2661    this DNSKEY RR.                                                         
 2662                                                                            
 2663    The RRSIG indicates the original TTL of the MX RRset was 3600, and,     
 2664    for the purpose of authentication, the current TTL is replaced by       
 2665    3600.  The RRSIG labels field value of 3 indicates that the answer      
 2666    was not the result of wildcard expansion.  The "x.w.example.com" MX     
 2667    RRset is placed in canonical form, and, assuming the current time       
 2668    falls between the signature inception and expiration dates, the         
 2669    signature is authenticated.                                             
 2670                                                                            
 2671 C.1.1.  Authenticating the Example DNSKEY RR                               
 2672                                                                            
 2673    This example shows the logical authentication process that starts       
 2674    from the a configured root DNSKEY (or DS RR) and moves down the tree    
 2675    to authenticate the desired "example" DNSKEY RR.  Note that the         
 2676    logical order is presented for clarity.  An implementation may choose   
 2677    to construct the authentication as referrals are received or to         
 2678    construct the authentication chain only after all RRsets have been      
 2679    obtained, or in any other combination it sees fit.  The example here    
 2680    demonstrates only the logical process and does not dictate any          
 2681    implementation rules.                                                   
 2682                                                                            
 2683    We assume the resolver starts with a configured DNSKEY RR for the       
 2684    root zone (or a configured DS RR for the root zone).  The resolver      
 2685    checks whether this configured DNSKEY RR is present in the root         
 2686    DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root      
 2687    DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY        
 2688    RRset, and whether the signature lifetime is valid.  If all these       
 2689                                                                            
 2690                                                                            
 2691                                                                            
 2692 Arends, et al.              Standards Track                    [Page 49]   

 2693 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2694                                                                            
 2695                                                                            
 2696    conditions are met, all keys in the DNSKEY RRset are considered         
 2697    authenticated.  The resolver then uses one (or more) of the root        
 2698    DNSKEY RRs to authenticate the "example" DS RRset.  Note that the       
 2699    resolver may have to query the root zone to obtain the root DNSKEY      
 2700    RRset or "example" DS RRset.                                            
 2701                                                                            
 2702    Once the DS RRset has been authenticated using the root DNSKEY, the     
 2703    resolver checks the "example" DNSKEY RRset for some "example" DNSKEY    
 2704    RR that matches one of the authenticated "example" DS RRs.  If such a   
 2705    matching "example" DNSKEY is found, the resolver checks whether this    
 2706    DNSKEY RR has signed the "example" DNSKEY RRset and the signature       
 2707    lifetime is valid.  If these conditions are met, all keys in the        
 2708    "example" DNSKEY RRset are considered authenticated.                    
 2709                                                                            
 2710    Finally, the resolver checks that some DNSKEY RR in the "example"       
 2711    DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This         
 2712    DNSKEY is used to authenticate the RRSIG included in the response.      
 2713    If multiple "example" DNSKEY RRs match this algorithm and key tag,      
 2714    then each DNSKEY RR is tried, and the answer is authenticated if any    
 2715    of the matching DNSKEY RRs validate the signature as described above.   
 2716                                                                            
 2717 C.2.  Name Error                                                           
 2718                                                                            
 2719    The query in Appendix B.2 returned NSEC RRs that prove that the         
 2720    requested data does not exist and no wildcard applies.  The negative    
 2721    reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are    
 2722    authenticated in a manner identical to that of the MX RRset discussed   
 2723    above.                                                                  
 2724                                                                            
 2725 C.3.  No Data Error                                                        
 2726                                                                            
 2727    The query in Appendix B.3 returned an NSEC RR that proves that the      
 2728    requested name exists, but the requested RR type does not exist.  The   
 2729    negative reply is authenticated by verifying the NSEC RR.  The NSEC     
 2730    RR is authenticated in a manner identical to that of the MX RRset       
 2731    discussed above.                                                        
 2732                                                                            
 2733 C.4.  Referral to Signed Zone                                              
 2734                                                                            
 2735    The query in Appendix B.4 returned a referral to the signed             
 2736    "a.example." zone.  The DS RR is authenticated in a manner identical    
 2737    to that of the MX RRset discussed above.  This DS RR is used to         
 2738    authenticate the "a.example" DNSKEY RRset.                              
 2739                                                                            
 2740    Once the "a.example" DS RRset has been authenticated using the          
 2741    "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset      
 2742    for some "a.example" DNSKEY RR that matches the DS RR.  If such a       
 2743    matching "a.example" DNSKEY is found, the resolver checks whether       
 2744                                                                            
 2745                                                                            
 2746                                                                            
 2747 Arends, et al.              Standards Track                    [Page 50]   

 2748 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2749                                                                            
 2750                                                                            
 2751    this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether      
 2752    the signature lifetime is valid.  If all these conditions are met,      
 2753    all keys in the "a.example" DNSKEY RRset are considered                 
 2754    authenticated.                                                          
 2755                                                                            
 2756 C.5.  Referral to Unsigned Zone                                            
 2757                                                                            
 2758    The query in Appendix B.5 returned a referral to an unsigned            
 2759    "b.example." zone.  The NSEC proves that no authentication leads from   
 2760    "example" to "b.example", and the NSEC RR is authenticated in a         
 2761    manner identical to that of the MX RRset discussed above.               
 2762                                                                            

Section 6.3 of RFC6840 says:

The text in Appendix C.1 of [RFC4035] refers to the examples in
Appendix B.1 as "x.w.example.com" while B.1 uses "x.w.example".  This
is painfully obvious in the second paragraph where it states that the
RRSIG labels field value of 3 indicates that the answer was not the
result of wildcard expansion.  This is true for "x.w.example" but not
for "x.w.example.com", which of course has a label count of 4
(antithetically, a label count of 3 would imply the answer was the
result of a wildcard expansion).

 2763 C.6.  Wildcard Expansion                                                   
 2764                                                                            
 2765    The query in Appendix B.6 returned an answer that was produced as a     
 2766    result of wildcard expansion.  The answer section contains a wildcard   
 2767    RRset expanded as it would be in a traditional DNS response, and the    
 2768    corresponding RRSIG indicates that the expanded wildcard MX RRset was   
 2769    signed by an "example" DNSKEY with algorithm 5 and key tag 38519.       
 2770    The RRSIG indicates that the original TTL of the MX RRset was 3600,     
 2771    and, for the purpose of authentication, the current TTL is replaced     
 2772    by 3600.  The RRSIG labels field value of 2 indicates that the answer   
 2773    is the result of wildcard expansion, as the "a.z.w.example" name        
 2774    contains 4 labels.  The name "a.z.w.w.example" is replaced by           
 2775    "*.w.example", the MX RRset is placed in canonical form, and,           
 2776    assuming that the current time falls between the signature inception    
 2777    and expiration dates, the signature is authenticated.                   
 2778                                                                            
 2779    The NSEC proves that no closer match (exact or closer wildcard) could   
 2780    have been used to answer this query, and the NSEC RR must also be       
 2781    authenticated before the answer is considered valid.                    
 2782                                                                            
 2783 C.7.  Wildcard No Data Error                                               
 2784                                                                            
 2785    The query in Appendix B.7 returned NSEC RRs that prove that the         
 2786    requested data does not exist and no wildcard applies.  The negative    
 2787    reply is authenticated by verifying both NSEC RRs.                      
 2788                                                                            

Section 6.3 of RFC6840 says:

The first paragraph of Appendix C.6 of [RFC4035] also has a minor
error: the reference to "a.z.w.w.example" should instead be
"a.z.w.example", as in the previous line.

 2789 C.8.  DS Child Zone No Data Error                                          
 2790                                                                            
 2791    The query in Appendix B.8 returned NSEC RRs that shows the requested    
 2792    was answered by a child server ("example" server).  The NSEC RR         
 2793    indicates the presence of an SOA RR, showing that the answer is from    
 2794    the child .  Queries for the "example" DS RRset should be sent to the   
 2795    parent servers ("root" servers).                                        
 2796                                                                            
 2797                                                                            
 2798                                                                            
 2799                                                                            
 2800                                                                            
 2801                                                                            
 2802 Arends, et al.              Standards Track                    [Page 51]   

 2803 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2804                                                                            
 2805                                                                            
 2806 Authors' Addresses                                                         
 2807                                                                            
 2808    Roy Arends                                                              
 2809    Telematica Instituut                                                    
 2810    Brouwerijstraat 1                                                       
 2811    7523 XC  Enschede                                                       
 2812    NL                                                                      
 2813                                                                            
 2814    EMail: roy.arends@telin.nl                                              
 2815                                                                            
 2816                                                                            
 2817    Rob Austein                                                             
 2818    Internet Systems Consortium                                             
 2819    950 Charter Street                                                      
 2820    Redwood City, CA  94063                                                 
 2821    USA                                                                     
 2822                                                                            
 2823    EMail: sra@isc.org                                                      
 2824                                                                            
 2825                                                                            
 2826    Matt Larson                                                             
 2827    VeriSign, Inc.                                                          
 2828    21345 Ridgetop Circle                                                   
 2829    Dulles, VA  20166-6503                                                  
 2830    USA                                                                     
 2831                                                                            
 2832    EMail: mlarson@verisign.com                                             
 2833                                                                            
 2834                                                                            
 2835    Dan Massey                                                              
 2836    Colorado State University                                               
 2837    Department of Computer Science                                          
 2838    Fort Collins, CO 80523-1873                                             
 2839                                                                            
 2840    EMail: massey@cs.colostate.edu                                          
 2841                                                                            
 2842                                                                            
 2843    Scott Rose                                                              
 2844    National Institute for Standards and Technology                         
 2845    100 Bureau Drive                                                        
 2846    Gaithersburg, MD  20899-8920                                            
 2847    USA                                                                     
 2848                                                                            
 2849    EMail: scott.rose@nist.gov                                              
 2850                                                                            
 2851                                                                            
 2852                                                                            
 2853                                                                            
 2854                                                                            
 2855                                                                            
 2856                                                                            
 2857 Arends, et al.              Standards Track                    [Page 52]   

 2858 RFC 4035             DNSSEC Protocol Modifications            March 2005   
 2859                                                                            
 2860                                                                            
 2861 Full Copyright Statement                                                   
 2862                                                                            
 2863    Copyright (C) The Internet Society (2005).                              
 2864                                                                            
 2865    This document is subject to the rights, licenses and restrictions       
 2866    contained in BCP 78, and except as set forth therein, the authors       
 2867    retain all their rights.                                                
 2868                                                                            
 2869    This document and the information contained herein are provided on an   
 2870    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   
 2871    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET      
 2872    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,     
 2873    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE           
 2874    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED          
 2875    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.      
 2876                                                                            
 2877 Intellectual Property                                                      
 2878                                                                            
 2879    The IETF takes no position regarding the validity or scope of any       
 2880    Intellectual Property Rights or other rights that might be claimed to   
 2881    pertain to the implementation or use of the technology described in     
 2882    this document or the extent to which any license under such rights      
 2883    might or might not be available; nor does it represent that it has      
 2884    made any independent effort to identify any such rights.  Information   
 2885    on the procedures with respect to rights in RFC documents can be        
 2886    found in BCP 78 and BCP 79.                                             
 2887                                                                            
 2888    Copies of IPR disclosures made to the IETF Secretariat and any          
 2889    assurances of licenses to be made available, or the result of an        
 2890    attempt made to obtain a general license or permission for the use of   
 2891    such proprietary rights by implementers or users of this                
 2892    specification can be obtained from the IETF on-line IPR repository at   
 2893    http://www.ietf.org/ipr.                                                
 2894                                                                            
 2895    The IETF invites any interested party to bring to its attention any     
 2896    copyrights, patents or patent applications, or other proprietary        
 2897    rights that may cover technology that may be required to implement      
 2898    this standard.  Please address the information to the IETF at ietf-     
 2899    ipr@ietf.org.                                                           
 2900                                                                            
 2901 Acknowledgement                                                            
 2902                                                                            
 2903    Funding for the RFC Editor function is currently provided by the        
 2904    Internet Society.                                                       
 2905                                                                            
 2906                                                                            
 2907                                                                            
 2908                                                                            
 2909                                                                            
 2910                                                                            
 2911                                                                            
 2912 Arends, et al.              Standards Track                    [Page 53]   
 2913                                                                            

Section 6.1 of RFC6840 says:

Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
for a parent zone but does not state how to find those servers.
Specific instructions can be found in Section 4.2 of [RFC4035].