1 Network Working Group                                          R. Arends   
    2 Request for Comments: 4033                          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).

RFC6014 says that it updates RFC 4033, but nothing in the text of RFC 6014 says why.

    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   
   14                DNS Security Introduction and Requirements                  
   16 Status of This Memo                                                        
   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.   
   24 Copyright Notice                                                           
   26    Copyright (C) The Internet Society (2005).                              
   28 Abstract                                                                   
   30    The Domain Name System Security Extensions (DNSSEC) add data origin     
   31    authentication and data integrity to the Domain Name System.  This      
   32    document introduces these extensions and describes their capabilities   
   33    and limitations.  This document also discusses the services that the    
   34    DNS security extensions do and do not provide.  Last, this document     
   35    describes the interrelationships between the documents that             
   36    collectively describe DNSSEC.                                           
   52 Arends, et al.              Standards Track                     [Page 1]   

   53 RFC 4033       DNS Security Introduction and Requirements     March 2005   
   56 Table of Contents                                                          
   58    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2    
   59    2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3    
   60    3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7    
   61        3.1.  Data Origin Authentication and Data Integrity  . . . .   7    
   62        3.2.  Authenticating Name and Type Non-Existence . . . . . .   9    
   63    4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9    
   64    5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9    
   65    6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10    
   66    7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11    
   67    8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12    
   68        8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13    
   69        8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13    
   70    9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13    
   71    10. DNS Security Document Family . . . . . . . . . . . . . . . .  14    
   72    11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15    
   73    12. Security Considerations  . . . . . . . . . . . . . . . . . .  15    
   74    13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17    
   75    14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17    
   76        14.1. Normative References . . . . . . . . . . . . . . . . .  17    
   77        14.2. Informative References . . . . . . . . . . . . . . . .  18    
   78    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20    
   79    Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21    
   81 1.  Introduction                                                           
   83    This document introduces the Domain Name System Security Extensions     
   84    (DNSSEC).  This document and its two companion documents ([RFC4034]     
   85    and [RFC4035]) update, clarify, and refine the security extensions      
   86    defined in [RFC2535] and its predecessors.  These security extensions   
   87    consist of a set of new resource record types and modifications to      
   88    the existing DNS protocol ([RFC1035]).  The new records and protocol    
   89    modifications are not fully described in this document, but are         
   90    described in a family of documents outlined in Section 10.  Sections    
   91    3 and 4 describe the capabilities and limitations of the security       
   92    extensions in greater detail.  Section 5 discusses the scope of the     
   93    document set.  Sections 6, 7, 8, and 9 discuss the effect that these    
   94    security extensions will have on resolvers, stub resolvers, zones,      
   95    and name servers.                                                       
   97    This document and its two companions obsolete [RFC2535], [RFC3008],     
   98    [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and   
   99    [RFC3845].  This document set also updates but does not obsolete        
  100    [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],       
  101    [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with      
  102    DNSSEC.                                                                 
  107 Arends, et al.              Standards Track                     [Page 2]   

  108 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  111    The DNS security extensions provide origin authentication and           
  112    integrity protection for DNS data, as well as a means of public key     
  113    distribution.  These extensions do not provide confidentiality.         
  115 2.  Definitions of Important DNSSEC Terms                                  
  117    This section defines a number of terms used in this document set.       
  118    Because this is intended to be useful as a reference while reading      
  119    the rest of the document set, first-time readers may wish to skim       
  120    this section quickly, read the rest of this document, and then come     
  121    back to this section.                                                   
  123    Authentication Chain: An alternating sequence of DNS public key         
  124       (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of   
  125       signed data, with each link in the chain vouching for the next.  A   
  126       DNSKEY RR is used to verify the signature covering a DS RR and       
  127       allows the DS RR to be authenticated.  The DS RR contains a hash     
  128       of another DNSKEY RR and this new DNSKEY RR is authenticated by      
  129       matching the hash in the DS RR.  This new DNSKEY RR in turn          
  130       authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in   
  131       this set may be used to authenticate another DS RR, and so forth     
  132       until the chain finally ends with a DNSKEY RR whose corresponding    
  133       private key signs the desired DNS data.  For example, the root       
  134       DNSKEY RRset can be used to authenticate the DS RRset for            
  135       "example."  The "example." DS RRset contains a hash that matches     
  136       some "example." DNSKEY, and this DNSKEY's corresponding private      
  137       key signs the "example." DNSKEY RRset.  Private key counterparts     
  138       of the "example." DNSKEY RRset sign data records such as             
  139       "www.example." and DS RRs for delegations such as                    
  140       "subzone.example."                                                   
  142    Authentication Key: A public key that a security-aware resolver has     
  143       verified and can therefore use to authenticate data.  A              
  144       security-aware resolver can obtain authentication keys in three      
  145       ways.  First, the resolver is generally configured to know about     
  146       at least one public key; this configured data is usually either      
  147       the public key itself or a hash of the public key as found in the    
  148       DS RR (see "trust anchor").  Second, the resolver may use an         
  149       authenticated public key to verify a DS RR and the DNSKEY RR to      
  150       which the DS RR refers.  Third, the resolver may be able to          
  151       determine that a new public key has been signed by the private key   
  152       corresponding to another public key that the resolver has            
  153       verified.  Note that the resolver must always be guided by local     
  154       policy when deciding whether to authenticate a new public key,       
  155       even if the local policy is simply to authenticate any new public    
  156       key for which the resolver is able verify the signature.             
  162 Arends, et al.              Standards Track                     [Page 3]   

  163 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  166    Authoritative RRset: Within the context of a particular zone, an        
  167       RRset is "authoritative" if and only if the owner name of the        
  168       RRset lies within the subset of the name space that is at or below   
  169       the zone apex and at or above the cuts that separate the zone from   
  170       its children, if any.  All RRsets at the zone apex are               
  171       authoritative, except for certain RRsets at this domain name that,   
  172       if present, belong to this zone's parent.  These RRset could         
  173       include a DS RRset, the NSEC RRset referencing this DS RRset (the    
  174       "parental NSEC"), and RRSIG RRs associated with these RRsets, all    
  175       of which are authoritative in the parent zone.  Similarly, if this   
  176       zone contains any delegation points, only the parental NSEC RRset,   
  177       DS RRsets, and any RRSIG RRs associated with these RRsets are        
  178       authoritative for this zone.                                         
  180    Delegation Point: Term used to describe the name at the parental side   
  181       of a zone cut.  That is, the delegation point for "foo.example"      
  182       would be the foo.example node in the "example" zone (as opposed to   
  183       the zone apex of the "foo.example" zone).  See also zone apex.       
  185    Island of Security: Term used to describe a signed, delegated zone      
  186       that does not have an authentication chain from its delegating       
  187       parent.  That is, there is no DS RR containing a hash of a DNSKEY    
  188       RR for the island in its delegating parent zone (see [RFC4034]).     
  189       An island of security is served by security-aware name servers and   
  190       may provide authentication chains to any delegated child zones.      
  191       Responses from an island of security or its descendents can only     
  192       be authenticated if its authentication keys can be authenticated     
  193       by some trusted means out of band from the DNS protocol.             
  195    Key Signing Key (KSK): An authentication key that corresponds to a      
  196       private key used to sign one or more other authentication keys for   
  197       a given zone.  Typically, the private key corresponding to a key     
  198       signing key will sign a zone signing key, which in turn has a        
  199       corresponding private key that will sign other zone data.  Local     
  200       policy may require that the zone signing key be changed              
  201       frequently, while the key signing key may have a longer validity     
  202       period in order to provide a more stable secure entry point into     
  203       the zone.  Designating an authentication key as a key signing key    
  204       is purely an operational issue: DNSSEC validation does not           
  205       distinguish between key signing keys and other DNSSEC                
  206       authentication keys, and it is possible to use a single key as       
  207       both a key signing key and a zone signing key.  Key signing keys     
  208       are discussed in more detail in [RFC3757].  Also see zone signing    
  209       key.                                                                 
  217 Arends, et al.              Standards Track                     [Page 4]   

  218 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  221    Non-Validating Security-Aware Stub Resolver: A security-aware stub      
  222       resolver that trusts one or more security-aware recursive name       
  223       servers to perform most of the tasks discussed in this document      
  224       set on its behalf.  In particular, a non-validating security-aware   
  225       stub resolver is an entity that sends DNS queries, receives DNS      
  226       responses, and is capable of establishing an appropriately secured   
  227       channel to a security-aware recursive name server that will          
  228       provide these services on behalf of the security-aware stub          
  229       resolver.  See also security-aware stub resolver, validating         
  230       security-aware stub resolver.                                        
  232    Non-Validating Stub Resolver: A less tedious term for a                 
  233       non-validating security-aware stub resolver.                         
  235    Security-Aware Name Server: An entity acting in the role of a name      
  236       server (defined in section 2.4 of [RFC1034]) that understands the    
  237       DNS security extensions defined in this document set.  In            
  238       particular, a security-aware name server is an entity that           
  239       receives DNS queries, sends DNS responses, supports the EDNS0        
  240       ([RFC2671]) message size extension and the DO bit ([RFC3225]), and   
  241       supports the RR types and message header bits defined in this        
  242       document set.                                                        
  244    Security-Aware Recursive Name Server: An entity that acts in both the   
  245       security-aware name server and security-aware resolver roles.  A     
  246       more cumbersome but equivalent phrase would be "a security-aware     
  247       name server that offers recursive service".                          
  249    Security-Aware Resolver: An entity acting in the role of a resolver     
  250       (defined in section 2.4 of [RFC1034]) that understands the DNS       
  251       security extensions defined in this document set.  In particular,    
  252       a security-aware resolver is an entity that sends DNS queries,       
  253       receives DNS responses, supports the EDNS0 ([RFC2671]) message       
  254       size extension and the DO bit ([RFC3225]), and is capable of using   
  255       the RR types and message header bits defined in this document set    
  256       to provide DNSSEC services.                                          
  258    Security-Aware Stub Resolver: An entity acting in the role of a stub    
  259       resolver (defined in section 5.3.1 of [RFC1034]) that has enough     
  260       of an understanding the DNS security extensions defined in this      
  261       document set to provide additional services not available from a     
  262       security-oblivious stub resolver.  Security-aware stub resolvers     
  263       may be either "validating" or "non-validating", depending on         
  264       whether the stub resolver attempts to verify DNSSEC signatures on    
  265       its own or trusts a friendly security-aware name server to do so.    
  266       See also validating stub resolver, non-validating stub resolver.     
  272 Arends, et al.              Standards Track                     [Page 5]   

  273 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  276    Security-Oblivious <anything>: An <anything> that is not                
  277       "security-aware".                                                    
  279    Signed Zone: A zone whose RRsets are signed and that contains           
  280       properly constructed DNSKEY, Resource Record Signature (RRSIG),      
  281       Next Secure (NSEC), and (optionally) DS records.                     
  283    Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A   
  284       validating security-aware resolver uses this public key or hash as   
  285       a starting point for building the authentication chain to a signed   
  286       DNS response.  In general, a validating resolver will have to        
  287       obtain the initial values of its trust anchors via some secure or    
  288       trusted means outside the DNS protocol.  Presence of a trust         
  289       anchor also implies that the resolver should expect the zone to      
  290       which the trust anchor points to be signed.                          
  292    Unsigned Zone: A zone that is not signed.                               
  294    Validating Security-Aware Stub Resolver: A security-aware resolver      
  295       that sends queries in recursive mode but that performs signature     
  296       validation on its own rather than just blindly trusting an           
  297       upstream security-aware recursive name server.  See also             
  298       security-aware stub resolver, non-validating security-aware stub     
  299       resolver.                                                            
  301    Validating Stub Resolver: A less tedious term for a validating          
  302       security-aware stub resolver.                                        
  304    Zone Apex: Term used to describe the name at the child's side of a      
  305       zone cut.  See also delegation point.                                
  307    Zone Signing Key (ZSK): An authentication key that corresponds to a     
  308       private key used to sign a zone.  Typically, a zone signing key      
  309       will be part of the same DNSKEY RRset as the key signing key whose   
  310       corresponding private key signs this DNSKEY RRset, but the zone      
  311       signing key is used for a slightly different purpose and may         
  312       differ from the key signing key in other ways, such as validity      
  313       lifetime.  Designating an authentication key as a zone signing key   
  314       is purely an operational issue; DNSSEC validation does not           
  315       distinguish between zone signing keys and other DNSSEC               
  316       authentication keys, and it is possible to use a single key as       
  317       both a key signing key and a zone signing key.  See also key         
  318       signing key.                                                         
  327 Arends, et al.              Standards Track                     [Page 6]   

  328 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  331 3.  Services Provided by DNS Security                                      
  333    The Domain Name System (DNS) security extensions provide origin         
  334    authentication and integrity assurance services for DNS data,           
  335    including mechanisms for authenticated denial of existence of DNS       
  336    data.  These mechanisms are described below.                            
  338    These mechanisms require changes to the DNS protocol.  DNSSEC adds      
  339    four new resource record types: Resource Record Signature (RRSIG),      
  340    DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure        
  341    (NSEC).  It also adds two new message header bits: Checking Disabled    
  342    (CD) and Authenticated Data (AD).  In order to support the larger DNS   
  343    message sizes that result from adding the DNSSEC RRs, DNSSEC also       
  344    requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support   
  345    for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a            
  346    security-aware resolver can indicate in its queries that it wishes to   
  347    receive DNSSEC RRs in response messages.                                
  349    These services protect against most of the threats to the Domain Name   
  350    System described in [RFC3833].  Please see Section 12 for a             
  351    discussion of the limitations of these extensions.                      
  353 3.1.  Data Origin Authentication and Data Integrity                        
  355    DNSSEC provides authentication by associating cryptographically         
  356    generated digital signatures with DNS RRsets.  These digital            
  357    signatures are stored in a new resource record, the RRSIG record.       
  358    Typically, there will be a single private key that signs a zone's       
  359    data, but multiple keys are possible.  For example, there may be keys   
  360    for each of several different digital signature algorithms.  If a       
  361    security-aware resolver reliably learns a zone's public key, it can     
  362    authenticate that zone's signed data.  An important DNSSEC concept is   
  363    that the key that signs a zone's data is associated with the zone       
  364    itself and not with the zone's authoritative name servers.  (Public     
  365    keys for DNS transaction authentication mechanisms may also appear in   
  366    zones, as described in [RFC2931], but DNSSEC itself is concerned with   
  367    object security of DNS data, not channel security of DNS                
  368    transactions.  The keys associated with transaction security may be     
  369    stored in different RR types.  See [RFC3755] for details.)              
  371    A security-aware resolver can learn a zone's public key either by       
  372    having a trust anchor configured into the resolver or by normal DNS     
  373    resolution.  To allow the latter, public keys are stored in a new       
  374    type of resource record, the DNSKEY RR.  Note that the private keys     
  375    used to sign zone data must be kept secure and should be stored         
  376    offline when practical.  To discover a public key reliably via DNS      
  377    resolution, the target key itself has to be signed by either a          
  378    configured authentication key or another key that has been              
  382 Arends, et al.              Standards Track                     [Page 7]   

  383 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  386    authenticated previously.  Security-aware resolvers authenticate zone   
  387    information by forming an authentication chain from a newly learned     
  388    public key back to a previously known authentication public key,        
  389    which in turn either has been configured into the resolver or must      
  390    have been learned and verified previously.  Therefore, the resolver     
  391    must be configured with at least one trust anchor.                      
  393    If the configured trust anchor is a zone signing key, then it will      
  394    authenticate the associated zone; if the configured key is a key        
  395    signing key, it will authenticate a zone signing key.  If the           
  396    configured trust anchor is the hash of a key rather than the key        
  397    itself, the resolver may have to obtain the key via a DNS query.  To    
  398    help security-aware resolvers establish this authentication chain,      
  399    security-aware name servers attempt to send the signature(s) needed     
  400    to authenticate a zone's public key(s) in the DNS reply message along   
  401    with the public key itself, provided that there is space available in   
  402    the message.                                                            
  404    The Delegation Signer (DS) RR type simplifies some of the               
  405    administrative tasks involved in signing delegations across             
  406    organizational boundaries.  The DS RRset resides at a delegation        
  407    point in a parent zone and indicates the public key(s) corresponding    
  408    to the private key(s) used to self-sign the DNSKEY RRset at the         
  409    delegated child zone's apex.  The administrator of the child zone, in   
  410    turn, uses the private key(s) corresponding to one or more of the       
  411    public keys in this DNSKEY RRset to sign the child zone's data.  The    
  412    typical authentication chain is therefore                               
  413    DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more            
  414    DS->DNSKEY subchains.  DNSSEC permits more complex authentication       
  415    chains, such as additional layers of DNSKEY RRs signing other DNSKEY    
  416    RRs within a zone.                                                      
  418    A security-aware resolver normally constructs this authentication       
  419    chain from the root of the DNS hierarchy down to the leaf zones based   
  420    on configured knowledge of the public key for the root.  Local          
  421    policy, however, may also allow a security-aware resolver to use one    
  422    or more configured public keys (or hashes of public keys) other than    
  423    the root public key, may not provide configured knowledge of the root   
  424    public key, or may prevent the resolver from using particular public    
  425    keys for arbitrary reasons, even if those public keys are properly      
  426    signed with verifiable signatures.  DNSSEC provides mechanisms by       
  427    which a security-aware resolver can determine whether an RRset's        
  428    signature is "valid" within the meaning of DNSSEC.  In the final        
  429    analysis, however, authenticating both DNS keys and data is a matter    
  430    of local policy, which may extend or even override the protocol         
  431    extensions defined in this document set.  See Section 5 for further     
  432    discussion.                                                             
  437 Arends, et al.              Standards Track                     [Page 8]   

  438 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  441 3.2.  Authenticating Name and Type Non-Existence                           
  443    The security mechanism described in Section 3.1 only provides a way     
  444    to sign existing RRsets in a zone.  The problem of providing negative   
  445    responses with the same level of authentication and integrity           
  446    requires the use of another new resource record type, the NSEC          
  447    record.  The NSEC record allows a security-aware resolver to            
  448    authenticate a negative reply for either name or type non-existence     
  449    with the same mechanisms used to authenticate other DNS replies.  Use   
  450    of NSEC records requires a canonical representation and ordering for    
  451    domain names in zones.  Chains of NSEC records explicitly describe      
  452    the gaps, or "empty space", between domain names in a zone and list     
  453    the types of RRsets present at existing names.  Each NSEC record is     
  454    signed and authenticated using the mechanisms described in Section      
  455    3.1.                                                                    
  457 4.  Services Not Provided by DNS Security                                  
  459    DNS was originally designed with the assumptions that the DNS will      
  460    return the same answer to any given query regardless of who may have    
  461    issued the query, and that all data in the DNS is thus visible.         
  462    Accordingly, DNSSEC is not designed to provide confidentiality,         
  463    access control lists, or other means of differentiating between         
  464    inquirers.                                                              
  466    DNSSEC provides no protection against denial of service attacks.        
  467    Security-aware resolvers and security-aware name servers are            
  468    vulnerable to an additional class of denial of service attacks based    
  469    on cryptographic operations.  Please see Section 12 for details.        
  471    The DNS security extensions provide data and origin authentication      
  472    for DNS data.  The mechanisms outlined above are not designed to        
  473    protect operations such as zone transfers and dynamic update            
  474    ([RFC2136], [RFC3007]).  Message authentication schemes described in    
  475    [RFC2845] and [RFC2931] address security operations that pertain to     
  476    these transactions.                                                     
  478 5.  Scope of the DNSSEC Document Set and Last Hop Issues                   
  480    The specification in this document set defines the behavior for zone    
  481    signers and security-aware name servers and resolvers in such a way     
  482    that the validating entities can unambiguously determine the state of   
  483    the data.                                                               
  485    A validating resolver can determine the following 4 states:             
  487    Secure: The validating resolver has a trust anchor, has a chain of      
  488       trust, and is able to verify all the signatures in the response.     
  492 Arends, et al.              Standards Track                     [Page 9]   

  493 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  496    Insecure: The validating resolver has a trust anchor, a chain of        
  497       trust, and, at some delegation point, signed proof of the            
  498       non-existence of a DS record.  This indicates that subsequent        
  499       branches in the tree are provably insecure.  A validating resolver   
  500       may have a local policy to mark parts of the domain space as         
  501       insecure.                                                            
  503    Bogus: The validating resolver has a trust anchor and a secure          
  504       delegation indicating that subsidiary data is signed, but the        
  505       response fails to validate for some reason: missing signatures,      
  506       expired signatures, signatures with unsupported algorithms, data     
  507       missing that the relevant NSEC RR says should be present, and so     
  508       forth.                                                               
  510    Indeterminate: There is no trust anchor that would indicate that a      
  511       specific portion of the tree is secure.  This is the default         
  512       operation mode.                                                      
  514    This specification only defines how security-aware name servers can     
  515    signal non-validating stub resolvers that data was found to be bogus    
  516    (using RCODE=2, "Server Failure"; see [RFC4035]).                       
  518    There is a mechanism for security-aware name servers to signal          
  519    security-aware stub resolvers that data was found to be secure (using   
  520    the AD bit; see [RFC4035]).                                             
  522    This specification does not define a format for communicating why       
  523    responses were found to be bogus or marked as insecure.  The current    
  524    signaling mechanism does not distinguish between indeterminate and      
  525    insecure states.                                                        
  527    A method for signaling advanced error codes and policy between a        
  528    security-aware stub resolver and security-aware recursive nameservers   
  529    is a topic for future work, as is the interface between a security-     
  530    aware resolver and the applications that use it.  Note, however, that   
  531    the lack of the specification of such communication does not prohibit   
  532    deployment of signed zones or the deployment of security aware          
  533    recursive name servers that prohibit propagation of bogus data to the   
  534    applications.                                                           
  536 6.  Resolver Considerations                                                
  538    A security-aware resolver has to be able to perform cryptographic       
  539    functions necessary to verify digital signatures using at least the     
  540    mandatory-to-implement algorithm(s).  Security-aware resolvers must     
  541    also be capable of forming an authentication chain from a newly         
  542    learned zone back to an authentication key, as described above.  This   
  543    process might require additional queries to intermediate DNS zones to   
  547 Arends, et al.              Standards Track                    [Page 10]   

  548 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  551    obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware       
  552    resolver should be configured with at least one trust anchor as the     
  553    starting point from which it will attempt to establish authentication   
  554    chains.                                                                 
  556    If a security-aware resolver is separated from the relevant             
  557    authoritative name servers by a recursive name server or by any sort    
  558    of intermediary device that acts as a proxy for DNS, and if the         
  559    recursive name server or intermediary device is not security-aware,     
  560    the security-aware resolver may not be capable of operating in a        
  561    secure mode.  For example, if a security-aware resolver's packets are   
  562    routed through a network address translation (NAT) device that          
  563    includes a DNS proxy that is not security-aware, the security-aware     
  564    resolver may find it difficult or impossible to obtain or validate      
  565    signed DNS data.  The security-aware resolver may have a particularly   
  566    difficult time obtaining DS RRs in such a case, as DS RRs do not        
  567    follow the usual DNS rules for ownership of RRs at zone cuts.  Note     
  568    that this problem is not specific to NATs: any security-oblivious DNS   
  569    software of any kind between the security-aware resolver and the        
  570    authoritative name servers will interfere with DNSSEC.                  
  572    If a security-aware resolver must rely on an unsigned zone or a name    
  573    server that is not security aware, the resolver may not be able to      
  574    validate DNS responses and will need a local policy on whether to       
  575    accept unverified responses.                                            
  577    A security-aware resolver should take a signature's validation period   
  578    into consideration when determining the TTL of data in its cache, to    
  579    avoid caching signed data beyond the validity period of the             
  580    signature.  However, it should also allow for the possibility that      
  581    the security-aware resolver's own clock is wrong.  Thus, a              
  582    security-aware resolver that is part of a security-aware recursive      
  583    name server will have to pay careful attention to the DNSSEC            
  584    "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid    
  585    blocking valid signatures from getting through to other                 
  586    security-aware resolvers that are clients of this recursive name        
  587    server.  See [RFC4035] for how a secure recursive server handles        
  588    queries with the CD bit set.                                            
  590 7.  Stub Resolver Considerations                                           
  592    Although not strictly required to do so by the protocol, most DNS       
  593    queries originate from stub resolvers.  Stub resolvers, by              
  594    definition, are minimal DNS resolvers that use recursive query mode     
  595    to offload most of the work of DNS resolution to a recursive name       
  596    server.  Given the widespread use of stub resolvers, the DNSSEC         
  602 Arends, et al.              Standards Track                    [Page 11]   

  603 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  606    architecture has to take stub resolvers into account, but the           
  607    security features needed in a stub resolver differ in some respects     
  608    from those needed in a security-aware iterative resolver.               
  610    Even a security-oblivious stub resolver may benefit from DNSSEC if      
  611    the recursive name servers it uses are security-aware, but for the      
  612    stub resolver to place any real reliance on DNSSEC services, the stub   
  613    resolver must trust both the recursive name servers in question and     
  614    the communication channels between itself and those name servers.       
  615    The first of these issues is a local policy issue: in essence, a        
  616    security-oblivious stub resolver has no choice but to place itself at   
  617    the mercy of the recursive name servers that it uses, as it does not    
  618    perform DNSSEC validity checks on its own.  The second issue requires   
  619    some kind of channel security mechanism; proper use of DNS              
  620    transaction authentication mechanisms such as SIG(0) ([RFC2931]) or     
  621    TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.      
  622    Particular implementations may have other choices available, such as    
  623    operating system specific interprocess communication mechanisms.        
  624    Confidentiality is not needed for this channel, but data integrity      
  625    and message authentication are.                                         
  627    A security-aware stub resolver that does trust both its recursive       
  628    name servers and its communication channel to them may choose to        
  629    examine the setting of the Authenticated Data (AD) bit in the message   
  630    header of the response messages it receives.  The stub resolver can     
  631    use this flag bit as a hint to find out whether the recursive name      
  632    server was able to validate signatures for all of the data in the       
  633    Answer and Authority sections of the response.                          
  635    There is one more step that a security-aware stub resolver can take     
  636    if, for whatever reason, it is not able to establish a useful trust     
  637    relationship with the recursive name servers that it uses: it can       
  638    perform its own signature validation by setting the Checking Disabled   
  639    (CD) bit in its query messages.  A validating stub resolver is thus     
  640    able to treat the DNSSEC signatures as trust relationships between      
  641    the zone administrators and the stub resolver itself.                   
  643 8.  Zone Considerations                                                    
  645    There are several differences between signed and unsigned zones.  A     
  646    signed zone will contain additional security-related records (RRSIG,    
  647    DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be           
  648    generated by a signing process prior to serving the zone.  The RRSIG    
  649    records that accompany zone data have defined inception and             
  650    expiration times that establish a validity period for the signatures    
  651    and the zone data the signatures cover.                                 
  657 Arends, et al.              Standards Track                    [Page 12]   

  658 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  661 8.1.  TTL Values vs. RRSIG Validity Period                                 
  663    It is important to note the distinction between a RRset's TTL value     
  664    and the signature validity period specified by the RRSIG RR covering    
  665    that RRset.  DNSSEC does not change the definition or function of the   
  666    TTL value, which is intended to maintain database coherency in          
  667    caches.  A caching resolver purges RRsets from its cache no later       
  668    than the end of the time period specified by the TTL fields of those    
  669    RRsets, regardless of whether the resolver is security-aware.           
  671    The inception and expiration fields in the RRSIG RR ([RFC4034]), on     
  672    the other hand, specify the time period during which the signature      
  673    can be used to validate the covered RRset.  The signatures associated   
  674    with signed zone data are only valid for the time period specified by   
  675    these fields in the RRSIG RRs in question.  TTL values cannot extend    
  676    the validity period of signed RRsets in a resolver's cache, but the     
  677    resolver may use the time remaining before expiration of the            
  678    signature validity period of a signed RRset as an upper bound for the   
  679    TTL of the signed RRset and its associated RRSIG RR in the resolver's   
  680    cache.                                                                  
  682 8.2.  New Temporal Dependency Issues for Zones                             
  684    Information in a signed zone has a temporal dependency that did not     
  685    exist in the original DNS protocol.  A signed zone requires regular     
  686    maintenance to ensure that each RRset in the zone has a current valid   
  687    RRSIG RR.  The signature validity period of an RRSIG RR is an           
  688    interval during which the signature for one particular signed RRset     
  689    can be considered valid, and the signatures of different RRsets in a    
  690    zone may expire at different times.  Re-signing one or more RRsets in   
  691    a zone will change one or more RRSIG RRs, which will in turn require    
  692    incrementing the zone's SOA serial number to indicate that a zone       
  693    change has occurred and re-signing the SOA RRset itself.  Thus,         
  694    re-signing any RRset in a zone may also trigger DNS NOTIFY messages     
  695    and zone transfer operations.                                           
  697 9.  Name Server Considerations                                             
  699    A security-aware name server should include the appropriate DNSSEC      
  700    records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries       
  701    from resolvers that have signaled their willingness to receive such     
  702    records via use of the DO bit in the EDNS header, subject to message    
  703    size limitations.  Because inclusion of these DNSSEC RRs could easily   
  704    cause UDP message truncation and fallback to TCP, a security-aware      
  705    name server must also support the EDNS "sender's UDP payload"           
  706    mechanism.                                                              
  712 Arends, et al.              Standards Track                    [Page 13]   

  713 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  716    If possible, the private half of each DNSSEC key pair should be kept    
  717    offline, but this will not be possible for a zone for which DNS         
  718    dynamic update has been enabled.  In the dynamic update case, the       
  719    primary master server for the zone will have to re-sign the zone when   
  720    it is updated, so the private key corresponding to the zone signing     
  721    key will have to be kept online.  This is an example of a situation     
  722    in which the ability to separate the zone's DNSKEY RRset into zone      
  723    signing key(s) and key signing key(s) may be useful, as the key         
  724    signing key(s) in such a case can still be kept offline and may have    
  725    a longer useful lifetime than the zone signing key(s).                  
  727    By itself, DNSSEC is not enough to protect the integrity of an entire   
  728    zone during zone transfer operations, as even a signed zone contains    
  729    some unsigned, nonauthoritative data if the zone has any children.      
  730    Therefore, zone maintenance operations will require some additional     
  731    mechanisms (most likely some form of channel security, such as TSIG,    
  732    SIG(0), or IPsec).                                                      
line-5 Mark Andrews(Technical Erratum #3043) [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

RFC 4033, 4034 and 4035 all list 3007 as being updated but none of them update 3007.
  734 10.  DNS Security Document Family                                          
  736    The DNSSEC document set can be partitioned into several main groups,    
  737    under the larger umbrella of the DNS base protocol documents.           
  739    The "DNSSEC protocol document set" refers to the three documents that   
  740    form the core of the DNS security extensions:                           
  742    1.  DNS Security Introduction and Requirements (this document)          
  744    2.  Resource Records for DNS Security Extensions [RFC4034]              
  746    3.  Protocol Modifications for the DNS Security Extensions [RFC4035]    
  748    Additionally, any document that would add to or change the core DNS     
  749    Security extensions would fall into this category.  This includes any   
  750    future work on the communication between security-aware stub            
  751    resolvers and upstream security-aware recursive name servers.           
  753    The "Digital Signature Algorithm Specification" document set refers     
  754    to the group of documents that describe how specific digital            
  755    signature algorithms should be implemented to fit the DNSSEC resource   
  756    record format.  Each document in this set deals with a specific         
  757    digital signature algorithm.  Please see the appendix on "DNSSEC        
  758    Algorithm and Digest Types" in [RFC4034] for a list of the algorithms   
  759    that were defined when this core specification was written.             
  761    The "Transaction Authentication Protocol" document set refers to the    
  762    group of documents that deal with DNS message authentication,           
  763    including secret key establishment and verification.  Although not      
  767 Arends, et al.              Standards Track                    [Page 14]   

  768 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  771    strictly part of the DNSSEC specification as defined in this set of     
  772    documents, this group is noted because of its relationship to DNSSEC.   
  774    The final document set, "New Security Uses", refers to documents that   
  775    seek to use proposed DNS Security extensions for other security         
  776    related purposes.  DNSSEC does not provide any direct security for      
  777    these new uses but may be used to support them.  Documents that fall    
  778    in this category include those describing the use of DNS in the         
  779    storage and distribution of certificates ([RFC2538]).                   
  781 11.  IANA Considerations                                                   
  783    This overview document introduces no new IANA considerations.  Please   
  784    see [RFC4034] for a complete review of the IANA considerations          
  785    introduced by DNSSEC.                                                   
  787 12.  Security Considerations                                               
  789    This document introduces DNS security extensions and describes the      
  790    document set that contains the new security records and DNS protocol    
  791    modifications.  The extensions provide data origin authentication and   
  792    data integrity using digital signatures over resource record sets.      
  793    This section discusses the limitations of these extensions.             
  795    In order for a security-aware resolver to validate a DNS response,      
  796    all zones along the path from the trusted starting point to the zone    
  797    containing the response zones must be signed, and all name servers      
  798    and resolvers involved in the resolution process must be                
  799    security-aware, as defined in this document set.  A security-aware      
  800    resolver cannot verify responses originating from an unsigned zone,     
  801    from a zone not served by a security-aware name server, or for any      
  802    DNS data that the resolver is only able to obtain through a recursive   
  803    name server that is not security-aware.  If there is a break in the     
  804    authentication chain such that a security-aware resolver cannot         
  805    obtain and validate the authentication keys it needs, then the          
  806    security-aware resolver cannot validate the affected DNS data.          
  808    This document briefly discusses other methods of adding security to a   
  809    DNS query, such as using a channel secured by IPsec or using a DNS      
  810    transaction authentication mechanism such as TSIG ([RFC2845]) or        
  811    SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC      
  812    per se.                                                                 
  814    A non-validating security-aware stub resolver, by definition, does      
  815    not perform DNSSEC signature validation on its own and thus is          
  816    vulnerable both to attacks on (and by) the security-aware recursive     
  817    name servers that perform these checks on its behalf and to attacks     
  818    on its communication with those security-aware recursive name           
  822 Arends, et al.              Standards Track                    [Page 15]   

  823 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  826    servers.  Non-validating security-aware stub resolvers should use       
  827    some form of channel security to defend against the latter threat.      
  828    The only known defense against the former threat would be for the       
  829    security-aware stub resolver to perform its own signature validation,   
  830    at which point, again by definition, it would no longer be a            
  831    non-validating security-aware stub resolver.                            
  833    DNSSEC does not protect against denial of service attacks.  DNSSEC      
  834    makes DNS vulnerable to a new class of denial of service attacks        
  835    based on cryptographic operations against security-aware resolvers      
  836    and security-aware name servers, as an attacker can attempt to use      
  837    DNSSEC mechanisms to consume a victim's resources.  This class of       
  838    attacks takes at least two forms.  An attacker may be able to consume   
  839    resources in a security-aware resolver's signature validation code by   
  840    tampering with RRSIG RRs in response messages or by constructing        
  841    needlessly complex signature chains.  An attacker may also be able to   
  842    consume resources in a security-aware name server that supports DNS     
  843    dynamic update, by sending a stream of update messages that force the   
  844    security-aware name server to re-sign some RRsets in the zone more      
  845    frequently than would otherwise be necessary.                           
  847    Due to a deliberate design choice, DNSSEC does not provide              
  848    confidentiality.                                                        
  850    DNSSEC introduces the ability for a hostile party to enumerate all      
  851    the names in a zone by following the NSEC chain.  NSEC RRs assert       
  852    which names do not exist in a zone by linking from existing name to     
  853    existing name along a canonical ordering of all the names within a      
  854    zone.  Thus, an attacker can query these NSEC RRs in sequence to        
  855    obtain all the names in a zone.  Although this is not an attack on      
  856    the DNS itself, it could allow an attacker to map network hosts or      
  857    other resources by enumerating the contents of a zone.                  
  859    DNSSEC introduces significant additional complexity to the DNS and      
  860    thus introduces many new opportunities for implementation bugs and      
  861    misconfigured zones.  In particular, enabling DNSSEC signature          
  862    validation in a resolver may cause entire legitimate zones to become    
  863    effectively unreachable due to DNSSEC configuration errors or bugs.     
  865    DNSSEC does not protect against tampering with unsigned zone data.      
  866    Non-authoritative data at zone cuts (glue and NS RRs in the parent      
  867    zone) are not signed.  This does not pose a problem when validating     
  868    the authentication chain, but it does mean that the non-authoritative   
  869    data itself is vulnerable to tampering during zone transfer             
  870    operations.  Thus, while DNSSEC can provide data origin                 
  871    authentication and data integrity for RRsets, it cannot do so for       
  872    zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be    
  873    used to protect zone transfer operations.                               
  877 Arends, et al.              Standards Track                    [Page 16]   

  878 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  881    Please see [RFC4034] and [RFC4035] for additional security              
  882    considerations.                                                         
  884 13.  Acknowledgements                                                      
  886    This document was created from the input and ideas of the members of    
  887    the DNS Extensions Working Group.  Although explicitly listing          
  888    everyone who has contributed during the decade in which DNSSEC has      
  889    been under development would be impossible, the editors would           
  890    particularly like to thank the following people for their               
  891    contributions to and comments on this document set: Jaap Akkerhuis,     
  892    Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,    
  893    David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald            
  894    Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,   
  895    Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip    
  896    Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,       
  897    Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon      
  898    Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,    
  899    Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,   
  900    Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ         
  901    Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob     
  902    Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,       
  903    Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,     
  904    Brian Wellington, and Suzanne Woolf.                                    
  906    No doubt the above list is incomplete.  We apologize to anyone we       
  907    left out.                                                               
  909 14.  References                                                            
  911 14.1.  Normative References                                                
  913    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",   
  914               STD 13, RFC 1034, November 1987.                             
  916    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  917               specification", STD 13, RFC 1035, November 1987.             
  919    [RFC2535]  Eastlake 3rd, D., "Domain Name System Security               
  920               Extensions", RFC 2535, March 1999.                           
  922    [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC       
  923               2671, August 1999.                                           
  925    [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC     
  926               3225, December 2001.                                         
  932 Arends, et al.              Standards Track                    [Page 17]   

  933 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  936    [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver   
  937               message size requirements", RFC 3226, December 2001.         
  939    [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY       
  940               Resource Record (RR)", RFC 3445, December 2002.              
  942    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  943               Rose, "Resource Records for DNS Security Extensions", RFC    
  944               4034, March 2005.                                            
  946    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.      
  947               Rose, "Protocol Modifications for the DNS Security           
  948               Extensions", RFC 4035, March 2005.                           
  950 14.2.  Informative References                                              
  952    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,           
  953               "Dynamic Updates in the Domain Name System (DNS UPDATE)",    
  954               RFC 2136, April 1997.                                        
  956    [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS              
  957               Specification", RFC 2181, July 1997.                         
  959    [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS           
  960               NCACHE)", RFC 2308, March 1998.                              
  962    [RFC2538]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates   
  963               in the Domain Name System (DNS)", RFC 2538, March 1999.      
  965    [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.         
  966               Wellington, "Secret Key Transaction Authentication for DNS   
  967               (TSIG)", RFC 2845, May 2000.                                 
  969    [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures    
  970               ( SIG(0)s )", RFC 2931, September 2000.                      
  972    [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic     
  973               Update", RFC 3007, November 2000.                            
  975    [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)        
  976               Signing Authority", RFC 3008, November 2000.                 
  978    [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone     
  979               Status", RFC 3090, March 2001.                               
  981    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record     
  982               (RR) Types", RFC 3597, September 2003.                       
  987 Arends, et al.              Standards Track                    [Page 18]   

  988 RFC 4033       DNS Security Introduction and Requirements     March 2005   
  991    [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS      
  992               Authenticated Data (AD) bit", RFC 3655, November 2003.       
  994    [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record     
  995               (RR)", RFC 3658, December 2003.                              
  997    [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation    
  998               Signer (DS)", RFC 3755, May 2004.                            
 1000    [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name        
 1001               System KEY (DNSKEY) Resource Record (RR) Secure Entry        
 1002               Point (SEP) Flag", RFC 3757, April 2004.                     
 1004    [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain    
 1005               Name System (DNS)", RFC 3833, August 2004.                   
 1007    [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)       
 1008               RDATA Format", RFC 3845, August 2004.                        
 1042 Arends, et al.              Standards Track                    [Page 19]   

 1043 RFC 4033       DNS Security Introduction and Requirements     March 2005   
 1046 Authors' Addresses                                                         
 1048    Roy Arends                                                              
 1049    Telematica Instituut                                                    
 1050    Brouwerijstraat 1                                                       
 1051    7523 XC  Enschede                                                       
 1052    NL                                                                      
 1054    EMail: roy.arends@telin.nl                                              
 1057    Rob Austein                                                             
 1058    Internet Systems Consortium                                             
 1059    950 Charter Street                                                      
 1060    Redwood City, CA  94063                                                 
 1061    USA                                                                     
 1063    EMail: sra@isc.org                                                      
 1066    Matt Larson                                                             
 1067    VeriSign, Inc.                                                          
 1068    21345 Ridgetop Circle                                                   
 1069    Dulles, VA  20166-6503                                                  
 1070    USA                                                                     
 1072    EMail: mlarson@verisign.com                                             
 1075    Dan Massey                                                              
 1076    Colorado State University                                               
 1077    Department of Computer Science                                          
 1078    Fort Collins, CO 80523-1873                                             
 1080    EMail: massey@cs.colostate.edu                                          
 1083    Scott Rose                                                              
 1084    National Institute for Standards and Technology                         
 1085    100 Bureau Drive                                                        
 1086    Gaithersburg, MD  20899-8920                                            
 1087    USA                                                                     
 1089    EMail: scott.rose@nist.gov                                              
 1097 Arends, et al.              Standards Track                    [Page 20]   

 1098 RFC 4033       DNS Security Introduction and Requirements     March 2005   
 1101 Full Copyright Statement                                                   
 1103    Copyright (C) The Internet Society (2005).                              
 1105    This document is subject to the rights, licenses and restrictions       
 1106    contained in BCP 78, and except as set forth therein, the authors       
 1107    retain all their rights.                                                
 1109    This document and the information contained herein are provided on an   
 1117 Intellectual Property                                                      
 1119    The IETF takes no position regarding the validity or scope of any       
 1120    Intellectual Property Rights or other rights that might be claimed to   
 1121    pertain to the implementation or use of the technology described in     
 1122    this document or the extent to which any license under such rights      
 1123    might or might not be available; nor does it represent that it has      
 1124    made any independent effort to identify any such rights.  Information   
 1125    on the procedures with respect to rights in RFC documents can be        
 1126    found in BCP 78 and BCP 79.                                             
 1128    Copies of IPR disclosures made to the IETF Secretariat and any          
 1129    assurances of licenses to be made available, or the result of an        
 1130    attempt made to obtain a general license or permission for the use of   
 1131    such proprietary rights by implementers or users of this                
 1132    specification can be obtained from the IETF on-line IPR repository at   
 1133    http://www.ietf.org/ipr.                                                
 1135    The IETF invites any interested party to bring to its attention any     
 1136    copyrights, patents or patent applications, or other proprietary        
 1137    rights that may cover technology that may be required to implement      
 1138    this standard.  Please address the information to the IETF at ietf-     
 1139    ipr@ietf.org.                                                           
 1141 Acknowledgement                                                            
 1143    Funding for the RFC Editor function is currently provided by the        
 1144    Internet Society.                                                       
 1152 Arends, et al.              Standards Track                    [Page 21]   

Section 2 of RFC6840 adds three documents to the DNSSEC core documentation set: