From: Mark Andrews Date: Tue, 6 Nov 2007 05:15:07 +0000 (+0000) Subject: new draft X-Git-Tag: v9.5.0a7~4 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ad5008ef7ef7903924323a7a2e2d88e7326d1fc7;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsext-nsec3-10.txt b/doc/draft/draft-ietf-dnsext-nsec3-10.txt deleted file mode 100644 index 898f910a5aa..00000000000 --- a/doc/draft/draft-ietf-dnsext-nsec3-10.txt +++ /dev/null @@ -1,5824 +0,0 @@ - - - -Network Working Group B. Laurie -Internet-Draft G. Sisson -Intended status: Standards Track R. Arends -Expires: July 5, 2007 Nominet - D. Blacka - VeriSign, Inc. - January 2007 - - - DNSSEC Hashed Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-10 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 5, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - The Domain Name System Security Extensions (DNSSEC) introduced the - NSEC resource record (RR) for authenticated denial of existence. - This document introduces an alternative resource record, NSEC3, which - similarly provides authenticated denial of existence. However, it - also provides measures against zone enumeration and permits gradual - - - -Laurie, et al. Expires July 5, 2007 [Page 1] - -Internet-Draft nsec3 January 2007 - - - expansion of delegation-centric zones. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 - 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 8 - 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8 - 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9 - 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 10 - 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 10 - 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 11 - 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 12 - 4. The NSEC3PARAM Record . . . . . . . . . . . . . . . . . . . . 12 - 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 13 - 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 14 - 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14 - 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 15 - 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. Authoritative Server Considerations . . . . . . . . . . . . . 16 - 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16 - 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18 - 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19 - 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19 - 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19 - 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 20 - 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20 - 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20 - 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20 - 7.2.9. Server Response to a Run-time Collision . . . . . . . 21 - 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21 - 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21 - - - -Laurie, et al. Expires July 5, 2007 [Page 2] - -Internet-Draft nsec3 January 2007 - - - 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21 - 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23 - 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23 - 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23 - 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23 - 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24 - 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24 - 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24 - 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25 - 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25 - 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25 - 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25 - 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26 - 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26 - 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26 - 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26 - 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26 - 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27 - 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28 - 10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 29 - 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 29 - 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30 - 12.1.3. Using New or Unknown Hash Algorithms . . . . . . . . . 30 - 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 30 - 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 31 - 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 - Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 33 - Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 38 - B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 38 - B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 40 - B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 41 - B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 42 - B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 44 - B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46 - B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 47 - Appendix C. Special Considerations . . . . . . . . . . . . . . . 48 - C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 48 - C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49 - C.2.1. Avoiding Hash Collisions During Generation . . . . . . 49 - C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 49 - C.2.3. Possible Hash Value Truncation Method . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 - - - -Laurie, et al. Expires July 5, 2007 [Page 3] - -Internet-Draft nsec3 January 2007 - - - Intellectual Property and Copyright Statements . . . . . . . . . . 52 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 4] - -Internet-Draft nsec3 January 2007 - - -1. Introduction - -1.1. Rationale - - The DNS Security Extensions included the NSEC RR to provide - authenticated denial of existence. Though the NSEC RR meets the - requirements for authenticated denial of existence, it introduces a - side-effect in that the contents of a zone can be enumerated. This - property introduces undesired policy issues. - - An enumerated zone can be used, for example, as a source of probable - e-mail addresses for spam, or as a key for multiple WHOIS queries to - reveal registrant data which many registries may have legal - obligations to protect. Many registries therefore prohibit copying - of their zone data; however, the use of NSEC RRs renders these - policies unenforceable. - - A second problem is that the cost to cryptographically secure - delegations to unsigned zones is high for large delegation-centric - zones and zones where insecure delegations will be updated rapidly. - For these zones, the costs of maintaining the NSEC RR chain may be - extremely high relative to the gain of cryptographically - authenticating existence of unsecured zones. - - This document presents the NSEC3 Resource Record which can be used as - an alternative to NSEC to mitigate these issues. - - Earlier work to address these issues include [I-D.jas-dnsext-no], - [I-D.ietf-dnsext-dnssec-opt-in] and [I-D.laurie-dnsext-nsec2v2]. - -1.2. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -1.3. Terminology - - The reader is assumed to be familiar with the basic DNS and DNSSEC - concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], - [RFC4035] and subsequent RFCs that update them: [RFC2136], [RFC2181] - and [RFC2308]. - - The following terminology is used throughout this document: - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 5] - -Internet-Draft nsec3 January 2007 - - - Zone enumeration: the practice of discovering the full content of a - zone via successive queries. Zone enumeration was non-trivial - prior to the introduction of DNSSEC. - - Original owner name: the owner name corresponding to a hashed owner - name. - - Hashed owner name: the owner name created after applying the hash - function to an owner name. - - Hash order: the order in which hashed owner names are arranged - according to their numerical value, treating the leftmost (lowest - numbered) octet as the most significant octet. Note that this - order is the same as the canonical DNS name order specified in - [RFC4034] when the hashed owner names are in base32 encoded with - Extended Hex Alphabet [RFC4648]. - - Empty non-terminal: a domain name that owns no resource records, but - has one or more subdomains that do. - - Delegation: an NS RRSet with a name different from the current zone - apex (non-zone-apex), signifying a delegation to a child zone. - - Secure delegation: a name containing a delegation (NS RRSet), and a - signed DS RRSet, signifying a delegation to a signed child zone. - - Insecure delegation: a name containing a delegation (NS RRSet), but - lacking a DS RRSet, signifying a delegation to an unsigned child - zone. - - Opt-Out NSEC3 resource record: an NSEC3 resource record which has - the Opt-Out flag set to 1. - - Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR. - - Closest encloser: the longest existing ancestor of a name. See also - section 3.3.1 of [RFC4592]. - - Closest provable encloser: the longest ancestor of a name that can - be proven to exist. Note that this is only different from the - closest encloser in an Opt-Out zone. - - Next closer name: the name one label longer than the closest - provable encloser of a name. - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 6] - -Internet-Draft nsec3 January 2007 - - - Base32: the "Base 32 Encoding with Extended Hex Alphabet" as - specified in [RFC4648]. Note that trailing padding characters - ("=") are not used in the NSEC3 specification. - - To cover: An NSEC3 RR is said to "cover" a name if the hash of the - name or "next closer" name falls between the owner name and the - next hashed owner name of the NSEC3. In other words, if it proves - the nonexistence of the name, either directly or by proving the - nonexistence of an ancestor of the name. - - To match: An NSEC3 RR is said to "match" a name if the owner name of - the NSEC3 RR is the same as the hashed owner name of that name. - - -2. Backwards Compatibility - - This specification describes a protocol change that is not generally - backwards compatible with [RFC4033], [RFC4034] and [RFC4035]. In - particular, security-aware resolvers that are unaware of this - specification (NSEC3-unaware resolvers) may fail to validate the - responses introduced by this document. - - In order to aid deployment, this specification uses a signaling - technique to prevent NSEC3-unaware resolvers from attempting to - validate responses from NSEC3-signed zones. - - This specification allocates two new DNSKEY algorithm identifiers for - this purpose. Algorithm XX, DSA-NSEC3 [### RFC-editor update - required, temporarily, XX=131] is an alias for algorithm 3, DSA. - Algorithm YY, RSASHA1-NSEC3 [### RFC-editor update required, - temporarily, YY=133] is an alias for algorithm 5, RSASHA1. These are - not new algorithms, they are simply additional identifiers for the - existing algorithms. - - Zones signed according to this specification MUST only use these - algorithm identifiers for their DNSKEY RRs. Because these new - identifiers will be unknown algorithms to existing, NSEC3-unaware - resolvers, those resolvers will then treat responses from the NSEC3 - signed zone as insecure, as detailed in [RFC4035], section 5.2. - - Security aware resolvers that are aware of this specification MUST - recognize the new algorithm identifiers and treat them as equivalent - to the algorithms that they alias. - - A methodology for transitioning from a DNSSEC signed zone to a zone - signed using NSEC3 is discussed in Section 10.4. - - - - - -Laurie, et al. Expires July 5, 2007 [Page 7] - -Internet-Draft nsec3 January 2007 - - -3. The NSEC3 Resource Record - - The NSEC3 Resource Record (RR) provides authenticated denial of - existence for DNS Resource Record Sets. - - The NSEC3 RR lists RR types present at the original owner name of the - NSEC3 RR. It includes the next hashed owner name in the hash order - of the zone. The complete set of NSEC3 RRs in a zone indicates which - RRSets exist for the original owner name of the RR and form a chain - of hashed owner names in the zone. This information is used to - provide authenticated denial of existence for DNS data. To provide - protection against zone enumeration, the owner names used in the - NSEC3 RR are cryptographic hashes of the original owner name - prepended as a single label to the name of the zone. The NSEC3 RR - indicates which hash function is used to construct the hash, which - salt is used, and how many iterations of the hash function are - performed over the original owner name. The hashing technique is - described fully in Section 5. - - Hashed owner names of unsigned delegations may be excluded from the - chain. An NSEC3 RR whose span covers the hash of an owner name or - "next closer" name of an unsigned delegation is referred to as an - Opt-Out NSEC3 RR and is indicated by the presence of a flag. - - The owner name for the NSEC3 RR is the base32 encoding of the hashed - owner name prepended as a single label to the name of the zone. - - The type value for the NSEC3 RR is NN. [### RFC-editor update - required, temporarily, NN=65324.] - - The NSEC3 RR RDATA format is class independent and is described - below. - - The class MUST be the same as the class of the original owner name. - - The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -3.1. RDATA Fields - -3.1.1. Hash Algorithm - - The Hash Algorithm field identifies the cryptographic hash algorithm - used to construct the hash-value. - - The values for this field are defined in the NSEC3 hash algorithm - registry, described in Section 11. - - - - -Laurie, et al. Expires July 5, 2007 [Page 8] - -Internet-Draft nsec3 January 2007 - - -3.1.2. Flags - - The Flags field contains 8 one-bit flags that can be used to indicate - different processing. All undefined flags must be zero. The only - flag defined by this specification is the Opt-Out flag. - -3.1.2.1. Opt-Out Flag - - The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned - delegations. It is the least significant bit in the Flags field. - See Section 6 for details about the use of this flag. - -3.1.3. Iterations - - The Iterations field defines the number of additional times the hash - function has been performed. More iterations result in greater - resiliency of the hash value against dictionary attacks, but at a - higher computational cost for both the server and resolver. See - Section 5 for details of the use of this field, and Section 10.3 for - limitations on the value. - -3.1.4. Salt Length - - The Salt Length field defines the length of the Salt field in octets, - ranging in value from 0 to 255. - -3.1.5. Salt - - The Salt field is appended to the original owner name before hashing - in order to defend against pre-calculated dictionary attacks. See - Section 5 for details on how the salt is used. - -3.1.6. Hash Length - - The Hash Length field defines the length of the Next Hashed Owner - Name field, ranging in value from 1 to 255 octets. - -3.1.7. Next Hashed Owner Name - - The Next Hashed Owner Name field contains the next hashed owner name - in hash order. This value is in binary format. Given the ordered - set of all hashed owner names, the Next Hashed Owner Name field - contains the hash of an owner name that immediately follows the owner - name of the given NSEC3 RR. The value of the Next Hashed Owner Name - field in the last NSEC3 RR in the zone is the same as the hashed - owner name of the first NSEC3 RR in the zone in hash order. Note - that, unlike the owner name of the NSEC3 RR, the value of this field - does not contain the appended zone name. - - - -Laurie, et al. Expires July 5, 2007 [Page 9] - -Internet-Draft nsec3 January 2007 - - -3.1.8. Type Bit Maps - - The Type Bit Maps field identifies the RRSet types which exist at the - original owner name of the NSEC3 RR. - -3.2. NSEC3 RDATA Wire Format - - The RDATA of the NSEC3 RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Alg. | Flags | Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Length | Next Hashed Owner Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Hash Algorithm is a single octet. - - Flags field is a single octet, the Opt-Out flag is the least - significant bit, as shown below: - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - | |O| - +-+-+-+-+-+-+-+-+ - - Iterations is represented as a 16-bit unsigned integer, with the most - significant bit first. - - Salt Length is represented as an unsigned octet. Salt Length - represents the length of the Salt field in octets. If the value is - zero, the following Salt field is omitted. - - Salt, if present, is encoded as a sequence of binary octets. The - length of this field is determined by the preceding Salt Length - field. - - Hash Length is represented as an unsigned octet. Hash Length - represents the length of the Next Hashed Owner Name field in octets. - - The next hashed owner name is not base32 encoded, unlike the owner - name of the NSEC3 RR. It is the unmodified binary hash value. It - does not include the name of the containing zone. The length of this - - - -Laurie, et al. Expires July 5, 2007 [Page 10] - -Internet-Draft nsec3 January 2007 - - - field is determined by the preceding Hash Length field. - -3.2.1. Type Bit Maps Encoding - - The encoding of the Type Bit Maps field is the same as that used by - the NSEC RR, described in [RFC4034]. It is explained and clarified - here for clarity. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the bitmap of the - window block, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC3 RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRSet of that type is present for the - original owner name of the NSEC3 RR. If a bit is set to 0, it - indicates that no RRSet of that type is present for the original - owner name of the NSEC3 RR. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in [RFC2929] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of the bitmap of - each block is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - original owner name of the NSEC3 RR. Trailing octets not specified - MUST be interpreted as zero octets. - - - - -Laurie, et al. Expires July 5, 2007 [Page 11] - -Internet-Draft nsec3 January 2007 - - -3.3. Presentation Format - - The presentation format of the RDATA portion is as follows: - - o The Hash Algorithm field is represented as an unsigned decimal - integer. The value has a maximum of 255. - - o The Flags field is represented as an unsigned decimal integer. - The value has a maximum of 255. - - o The Iterations field is represented as an unsigned decimal - integer. The value is between 0 and 65535, inclusive. - - o The Salt Length field is not represented. - - o The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the - sequence. The Salt field is represented as "-" (without the - quotes) when the Salt Length field has value 0. - - o The Hash Length field is not represented. - - o The Next Hashed Owner Name field is represented as an unpadded - sequence of case-insensitive base32 digits, without whitespace. - - o The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE - representation as described in [RFC3597] (section 5) MUST be used. - - -4. The NSEC3PARAM Record - - The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, - flags, iterations and salt) needed to calculate hashed owner names. - The presence of an NSEC3PARAM RR at a zone apex indicates that the - specified parameters may be used by authoritative servers to choose - an appropriate set of NSEC3 RRs for negative responses. - - If an NSEC3PARAM RR is present at the apex of a zone with a Flags - field value of zero, then there MUST be an NSEC3 using the same hash - algorithm, iterations and salt parameters present at every hashed - owner name in the zone. That is, the zone MUST contain a complete - set of NSEC3 RRs with the same hash algorithm, iterations and salt - parameters. - - The owner name for the NSEC3PARAM RR is the name of the zone apex. - - The type value for the NSEC3PARAM RR is MM. [### RFC-editor update - - - -Laurie, et al. Expires July 5, 2007 [Page 12] - -Internet-Draft nsec3 January 2007 - - - required, temporarily, MM=65325.] - - The NSEC3PARAM RR RDATA format is class independent and is described - below. - - The class MUST be the same as the NSEC3 RRs to which this RR refers. - -4.1. RDATA Fields - - The RDATA for this RR mirrors the first four fields in the NSEC3 RR. - -4.1.1. Hash Algorithm - - The Hash Algorithm field identifies the cryptographic hash algorithm - used to construct the hash-value. - - The acceptable values are the same as the corresponding field in the - NSEC3 RR. - -4.1.2. Flag Fields - - The Opt-Out flag is not used and is set to zero. - - All other flags reserved are for future use, and must be zero. - - NSEC3PARAM RRs with a Flags field value other than zero MUST be - ignored. - -4.1.3. Iterations - - The Iterations field defines the number of additional times the hash - is performed. - - Its acceptable values are the same as the corresponding field in the - NSEC3 RR. - -4.1.4. Salt Length - - The Salt Length field defines the length of the salt in octets, - ranging in value from 0 to 255. - -4.1.5. Salt - - The Salt field is appended to the original owner name before hashing. - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 13] - -Internet-Draft nsec3 January 2007 - - -4.2. NSEC3PARAM RDATA Wire Format - - The RDATA of the NSEC3PARAM RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Alg. | Flags | Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Hash Algorithm is a single octet. - - Flags field is a single octet. - - Iterations is represented as a 16-bit unsigned integer, with the most - significant bit first. - - Salt Length is represented as an unsigned octet. Salt Length - represents the length of the following Salt field in octets. If the - value is zero, the Salt field is omitted. - - Salt, if present, is encoded as a sequence of binary octets. The - length of this field is determined by the preceding Salt Length - field. - -4.3. Presentation Format - - The presentation format of the RDATA portion is as follows: - - o The Hash Algorithm field is represented as an unsigned decimal - integer. The value has a maximum of 255. - - o The Flags field is represented as an unsigned decimal integer. - The value has a maximum value of 255. - - o The Iterations field is represented as an unsigned decimal - integer. The value is between 0 and 65535, inclusive. - - o The Salt Length field is not represented. - - o The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the - sequences. This field is represented as "-" (without the quotes) - when the Salt Length field is zero. - - - - - -Laurie, et al. Expires July 5, 2007 [Page 14] - -Internet-Draft nsec3 January 2007 - - -5. Calculation of the Hash - - The hash calculation uses three of the NSEC3 RDATA fields: Hash - Algorithm, Salt, and Iterations. - - Define H(x) to be the hash of x using the Hash Algorithm selected by - the NSEC3 RR, k to be the number of Iterations, and || to indicate - concatenation. Then define: - - IH(salt, x, 0) = H(x || salt), and - - IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0 - - Then the calculated hash of an owner name is - - IH(salt, owner name, iterations), - - where the owner name is in the canonical form, defined as: - - The wire format of the owner name where: - - 1. The owner name is fully expanded (no DNS name compression) and - fully qualified; - - 2. All uppercase US-ASCII letters are replaced by the corresponding - lowercase US-ASCII letters; - - 3. If the owner name is a wildcard name, the owner name is in its - original unexpanded form, including the "*" label (no wildcard - substitution); - - This form is as defined in section 6.2 of [RFC4034]. - - -6. Opt-Out - - In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS - RRSets at delegation points are not signed and may be accompanied by - a DS RRSet. With the Opt-Out bit clear, the security status of the - child zone is determined by the presence or absence of this DS RRSet, - cryptographically proven by the signed NSEC3 RR at the hashed owner - name of the delegation. Setting the Opt-Out flag modifies this by - allowing insecure delegations to exist within the signed zone without - a corresponding NSEC3 RR at the hashed owner name of the delegation. - - An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the - owner name or "next closer" name of the delegation is between the - owner name of the NSEC3 RR and the next hashed owner name. - - - -Laurie, et al. Expires July 5, 2007 [Page 15] - -Internet-Draft nsec3 January 2007 - - - An Opt-Out NSEC3 RR does not assert the existence or non-existence of - the insecure delegations that it may cover. This allows for the - addition or removal of these delegations without recalculating or re- - signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do - assert the (non)existence of other, authoritative RRSets. - - An Opt-Out NSEC3 RR MAY have the same original owner name as an - insecure delegation. In this case, the delegation is proven insecure - by the lack of a DS bit in the type map and the signed NSEC3 RR does - assert the existence of the delegation. - - Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and - non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT - be any hashed owner names of insecure delegations (nor any other RRs) - between it and the name indicated by the next hashed owner name in - the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner - names or hashed "next closer" names of insecure delegations. - - The effects of the Opt-Out flag on signing, serving, and validating - responses are covered in following sections. - - -7. Authoritative Server Considerations - -7.1. Zone Signing - - Zones using NSEC3 must satisfy the following properties: - - o Each owner name within the zone that owns authoritative RRSets - MUST have a corresponding NSEC3 RR. Owner names that correspond - to unsigned delegations MAY have a corresponding NSEC3 RR. - However, if there is not a corresponding NSEC3 RR, there MUST be - an Opt-Out NSEC3 RR that covers the "next closer" name to the - delegation. Other non-authoritative RRs are not represented by - NSEC3 RRs. - - o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless - the empty non-terminal is only derived from an insecure delegation - covered by an Opt-Out NSEC3 RR. - - o The TTL value for any NSEC3 RR SHOULD be the same as the minimum - TTL value field in the zone SOA RR. - - o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST - indicate the presence of all types present at the original owner - name, except for the types solely contributed by an NSEC3 RR - itself. Note that this means that the NSEC3 type itself will - never be present in the Type Bit Maps. - - - -Laurie, et al. Expires July 5, 2007 [Page 16] - -Internet-Draft nsec3 January 2007 - - - The following steps describe a method of proper construction of NSEC3 - RRs. This is not the only such possible method. - - 1. For each unique original owner name in the zone add an NSEC3 RR. - - * If Opt-Out is being used, owner names of unsigned delegations - MAY be excluded. - - * The owner name of the NSEC3 RR is the hash of the original - owner name, prepended as a single label to the zone name. - - * The Next Hashed Owner Name field is left blank for the moment. - - * If Opt-Out is being used, set the Opt-Out bit to one. - - * For collision detection purposes, optionally keep track of the - original owner name with the NSEC3 RR. - - * Additionally, for collision detection purposes, optionally - create an additional NSEC3 RR corresponding to the original - owner name with the asterisk label prepended (i.e., as if a - wildcard existed as a child of this owner name) and keep track - of this original owner name. Mark this NSEC3 RR as temporary. - - 2. For each RRSet at the original owner name, set the corresponding - bit in the Type Bit Maps field. - - 3. If the difference in number of labels between the apex and the - original owner name is greater than 1, additional NSEC3 RRs need - to be added for every empty non-terminal between the apex and the - original owner name. This process may generate NSEC3 RRs with - duplicate hashed owner names. Optionally, for collision - detection, track the original owner names of these NSEC3 RRs and - create temporary NSEC3 RRs for wildcard collisions in a similar - fashion to step 1. - - 4. Sort the set of NSEC3 RRs into hash order. - - 5. Combine NSEC3 RRs with identical hashed owner names by replacing - them with a single NSEC3 RR with the Type Bit Maps field - consisting of the union of the types represented by the set of - NSEC3 RRs. If the original owner name was tracked, then - collisions may be detected when combining, as all of the matching - NSEC3 RRs should have the same original owner name. Discard any - possible temporary NSEC3 RRs. - - 6. In each NSEC3 RR, insert the next hashed owner name by using the - value of the next NSEC3 RR in hash order. The next hashed owner - - - -Laurie, et al. Expires July 5, 2007 [Page 17] - -Internet-Draft nsec3 January 2007 - - - name of the last NSEC3 RR in the zone contains the value of the - hashed owner name of the first NSEC3 RR in the hash order. - - 7. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, - Iterations and Salt fields to the zone apex. - - If a hash collision is detected, then a new salt has to be chosen and - the signing process restarted. - -7.2. Zone Serving - - This specification modifies DNSSEC-enabled DNS responses generated by - authoritative servers. In particular, it replaces the use of NSEC - RRs in such responses with NSEC3 RRs. - - In the following response cases, the NSEC RRs dictated by DNSSEC - [RFC4035] are replaced with NSEC3 RRs that prove the same facts. - Responses that would not contain NSEC RRs are unchanged by this - specification. - - When returning responses containing multiple NSEC3 RRs, all of the - NSEC3 RRs MUST use the same hash algorithm, iteration, and salt - values. The Flags field value MUST be either zero or one. - -7.2.1. Closest Encloser Proof - - For many NSEC3 responses a proof of the closest encloser is required. - This is a proof that some ancestor of the QNAME is the closest - encloser of QNAME. - - This proof consists of (up to) two different NSEC3 RRs: - - o An NSEC3 RR that matches the closest (provable) encloser. - - o An NSEC3 RR that covers the "next closer" name to the closest - encloser. - - The first NSEC3 RR essentially proposes a possible closest encloser, - and proves that the particular encloser does, in fact, exist. The - second NSEC3 RR proves that the possible closest encloser is the - closest, and proves that QNAME (and any ancestors between QNAME and - the closest encloser) do not exist. - - These NSEC3 RRs are collectively referred to as the "closest encloser - proof" in the subsequent descriptions. - - For example, the closest encloser proof for the nonexistent - "alpha.beta.gamma.example." owner name might prove that - - - -Laurie, et al. Expires July 5, 2007 [Page 18] - -Internet-Draft nsec3 January 2007 - - - "gamma.example." is the closest encloser. This response would - contain the NSEC3 RR that matches "gamma.example.", and would also - contain the NSEC3 RR that covers "beta.gamma.example." (which is the - "next closer" name.) - - It is possible, when using Opt-Out (Section 6), to not be able to - prove the actual closest encloser because it is, or is part of an - insecure delegation covered by an Opt-Out span. In this case, - instead of proving the actual closest encloser, the closest provable - encloser is used. That is, the closest enclosing authoritative name - is used instead. In this case, the set of NSEC3 RRs used for this - proof is referred to as the "closest provable encloser proof." - -7.2.2. Name Error Responses - - To prove the nonexistence of QNAME a closest encloser proof and an - NSEC3 RR covering the (nonexistent) wildcard RR at the closest - encloser MUST be included in the response. This collection of (up - to) three NSEC3 RRs proves both that QNAME does not exist and that a - wildcard that could have matched QNAME also does not exist. - - For example, if "gamma.example." is the closest provable encloser to - QNAME, then a NSEC3 RR covering "*.gamma.example." is included in the - authority section of the response. - -7.2.3. No Data Responses, QTYPE is not DS - - The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 - RR MUST NOT have the bits corresponding to either the QTYPE or CNAME - set in its Type Bit Maps field. - -7.2.4. No Data Responses, QTYPE is DS - - If there is an NSEC3 RR that matches QNAME, the server MUST return it - in the response. The bits corresponding with DS and CNAME MUST NOT - be set in the Type Bit Maps field of this NSEC3 RR. - - If no NSEC3 RR matches QNAME, the server MUST return a closest - provable encloser proof for QNAME. The NSEC3 RR that covers the - "next closer" name MUST have the Opt-Out bit set (note that this is - true by definition - if the Opt-Out bit is not set, something has - gone wrong). - - If a server is authoritative for both sides of a zone cut at QNAME, - the server MUST return the proof from the parent side of the zone - cut. - - - - - -Laurie, et al. Expires July 5, 2007 [Page 19] - -Internet-Draft nsec3 January 2007 - - -7.2.5. Wildcard No Data Responses - - If there is a wildcard match for QNAME, but QTYPE is not present at - that name, the response MUST include a closest encloser proof for - QNAME and MUST include the NSEC3 RR that matches the wildcard. This - combination proves both that QNAME itself does not exist and that a - wildcard that matches QNAME does exist. Note that the closest - encloser to QNAME MUST be the immediate ancestor of the wildcard RR - (if this is not the case, then something has gone wrong). - -7.2.6. Wildcard Answer Responses - - If there is a wildcard match for QNAME and QTYPE, then, in addition - to the expanded wildcard RRSet returned in the answer section of the - response, proof that the wildcard match was valid must be returned. - - This proof is accomplished by proving that both QNAME does not exist, - and that the closest encloser of the QNAME and the immediate ancestor - of the wildcard are the same (i.e., the correct wildcard matched). - - To this end, the NSEC3 RR that covers the "next closer" name of the - immediate ancestor of the wildcard MUST be returned. It is not - necessary to return an NSEC3 RR that matches the closest encloser, as - the existence of this closest encloser is proven by the presence of - the expanded wildcard in the response. - -7.2.7. Referrals to Unsigned Subzones - - If there is an NSEC3 RR that matches the delegation name, then that - NSEC3 RR MUST be included in the response. The DS bit in the type - bit maps of the NSEC3 RR MUST NOT be set. - - If the zone is Opt-Out, then there may not be an NSEC3 RR - corresponding to the delegation. In this case, the closest provable - encloser proof MUST be included in the response. The included NSEC3 - RR that covers the "next closer" name for the delegation MUST have - the Opt-Out flag set to one. (Note that this will be the case unless - something has gone wrong). - -7.2.8. Responding to Queries for NSEC3 Owner Names - - The owner names of NSEC3 RRs are not represented in the NSEC3 RR - chain like other owner names. As a result, each NSEC3 owner name is - covered by another NSEC3 RR, effectively negating the existence of - the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR - can be proven by its RRSIG RRSet. - - If the following conditions are all true: - - - -Laurie, et al. Expires July 5, 2007 [Page 20] - -Internet-Draft nsec3 January 2007 - - - o The QNAME equals the owner name of an existing NSEC3 RR, and - - o No RR types exist at the QNAME, nor at any descendant of QNAME. - - Then the response MUST be constructed as a Name Error response - (Section 7.2.2). Or, in other words, the authoritative name server - will act, as if the owner name of the NSEC3 RR did not exist. - - Note that NSEC3 RRs are returned as a result of an AXFR or IXFR - query. - -7.2.9. Server Response to a Run-time Collision - - If the hash of a non-existing QNAME collides with the owner name of - an existing NSEC3 RR, then the server will be unable to return a - response that proves that QNAME does not exist. In this case, the - server MUST return a response with an RCODE of 2 (server failure). - - Note that with the hash algorithm specified in this document, SHA-1, - such collisions are highly unlikely. - -7.3. Secondary Servers - - Secondary servers (and perhaps other entities) need to reliably - determine which NSEC3 parameters (i.e., hash, salt and iterations) - are present at every hashed owner name, in order to be able to choose - an appropriate set of NSEC3 RRs for negative responses. This is - indicated by an NSEC3PARAM RR present at the zone apex. - - If there are multiple NSEC3PARAM RRs present, there are multiple - valid NSEC3 chains present. The server must choose one of them, but - may use any criteria to do so. - -7.4. Zones Using Unknown Hash Algorithms - - Zones that are signed according to this specification, but are using - an unrecognized NSEC3 hash algorithm value, cannot be effectively - served. Such zones SHOULD be rejected when loading. Servers SHOULD - respond with RCODE=2 (server failure) responses when handling queries - that would fall under such zones. - -7.5. Dynamic Update - - A zone signed using NSEC3 may accept dynamic updates [RFC2136]. - However, NSEC3 introduces some special considerations for dynamic - updates. - - Adding and removing names in a zone MUST account for the creation or - - - -Laurie, et al. Expires July 5, 2007 [Page 21] - -Internet-Draft nsec3 January 2007 - - - removal of empty non-terminals. - - o When removing a name with a corresponding NSEC3, checks must be - made to remove any NSEC3 RRs corresponding with possible empty - non-terminals created by the name. Note that more than one name - may be asserting the existence of a particular empty non-terminal. - - o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs - MUST also be added for any empty non-terminals that are created. - That is, if there is not an existing NSEC3 RR matching an empty - non-terminal, it must be created and added. - - The presence of Opt-Out in a zone means that some additions or - delegations of names will not require changes to the NSEC3 RRs in a - zone. - - o When removing a delegation RRSet, if that delegation does not have - a matching NSEC3 RR, then it was opted out. In this case, nothing - further needs to be done. - - o When adding a delegation RRSet, if the "next closer" name of the - delegation is covered by an existing Opt-Out NSEC3 RR, then the - delegation MAY be added without modifying the NSEC3 RRs in the - zone. - - The presence of Opt-Out in a zone means that when adding or removing - NSEC3 RRs, the value of the Opt-Out flag that should be set in new or - modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of - basic rules to resolve the ambiguity. - - The central concept to these rules is that the state of the Opt-Out - flag of the covering NSEC3 RR is preserved. - - o When removing an NSEC3 RR, the value of the Opt-Out flag for the - previous NSEC3 RR (the one whose next hashed owner name is - modified) should not be changed. - - o When adding an NSEC3 RR, the value of the Opt-Out flag is set to - the value of the Opt-Out flag of the NSEC3 RR that previously - covered the owner name of the NSEC3 RR. That is, the now previous - NSEC3 RR. - - If the zone in question is consistent with its use of the Opt-Out - flag (that is, all NSEC3 RRs in the zone have the same value for the - flag) then these rules will retain that consistency. If the zone is - not consistent in the use of the flag (i.e., a partially Opt-Out - zone), then these rules will not retain the same pattern of use of - the Opt-Out flag. - - - -Laurie, et al. Expires July 5, 2007 [Page 22] - -Internet-Draft nsec3 January 2007 - - - For zones that partially use the Opt-Out flag, if there is a logical - pattern for that use, the pattern could be maintained by using a - local policy on the server. - - -8. Validator Considerations - -8.1. Responses with Unknown Hash Types - - A validator MUST ignore NSEC3 RRs with unknown hash types. The - practical result of this is that responses containing only such NSEC3 - RRs will generally be considered bogus. - -8.2. Verifying NSEC3 RRs - - A validator MUST ignore NSEC3 RRs with a Flag fields value other than - zero or one. - - A validator MAY treat a response as bogus if the response contains - NSEC3 RRs that contain different values for hash algorithm, - iterations, or salt from each other. - -8.3. Closest Encloser Proof - - In order to verify a closest encloser proof, the validator MUST find - the longest name, X, such that - - o X is an ancestor of QNAME that is matched by an NSEC3 RR present - in the response. This is a candidate for the closest encloser. - And: - - o The name one label longer than X (but still an ancestor of--or - equal to--QNAME) is covered by an NSEC3 RR present in the - response. - - One possible algorithm for verifying this proof is as follows: - - 1. Set SNAME=QNAME. Clear the flag. - - 2. Check whether SNAME exists: - - * If there is no NSEC3 RR in the response that matches SNAME - (i.e., an NSEC3 RR whose owner name is the same as the hash of - SNAME, prepended as a single label to the zone name), clear - the flag. - - * If there is an NSEC3 RR in the response that covers SNAME, set - the flag. - - - -Laurie, et al. Expires July 5, 2007 [Page 23] - -Internet-Draft nsec3 January 2007 - - - * If there is a matching NSEC3 RR in the response and the flag - was set, then the proof is complete, and SNAME is the closest - encloser. - - * If there is a matching NSEC3 RR in the response, but the flag - is not set, then the response is bogus. - - 3. Truncate SNAME by one label from the left, go to step 2. - - Once the closest encloser has been discovered, the validator MUST - check that the NSEC3 RR that has the closest encloser as the original - owner name is from the proper zone. The DNAME type bit must not be - set and the NS type bit may only be set if the SOA type bit is set. - If this is not the case, it would be an indication that an attacker - is using them to falsely deny the existence of RRs for which the - server is not authoritative. - - In the following descriptions, the phrase "a closest (provable) - encloser proof for X" means that the algorithm above (or an - equivalent algorithm) proves that X does not exist by proving that an - ancestor of X is its closest encloser. - -8.4. Validating Name Error Responses - - A validator MUST verify that there is a closest encloser proof for - QNAME present in the response and that there is an NSEC3 RR that - covers the wildcard at the closest encloser (i.e., the name formed by - prepending the asterisk label to the closest encloser.) - -8.5. Validating No Data Responses, QTYPE is not DS - - The validator MUST verify that an NSEC3 RR that matches QNAME is - present and that both the QTYPE and the CNAME type are not set in its - Type Bit Maps field. - - Note that this test also covers the case where the NSEC3 RR exists - because it corresponds to an empty non-terminal, in which case the - NSEC3 RR will have an empty Type Bit Maps field. - -8.6. Validating No Data Responses, QTYPE is DS - - If there is an NSEC3 RR that matches QNAME present in the response, - then that NSEC3 RR MUST NOT have the bits corresponding to DS and - CNAME set in its Type Bit Maps field. - - If there is no such NSEC3 RR, then the validator MUST verify that a - closest provable encloser proof for QNAME is present in the response, - and that the NSEC3 RR that covers the "next closer" name has the Opt- - - - -Laurie, et al. Expires July 5, 2007 [Page 24] - -Internet-Draft nsec3 January 2007 - - - Out bit set. - -8.7. Validating Wildcard No Data Responses - - The validator MUST verify a closest encloser proof for QNAME and MUST - find an NSEC3 RR present in the response that matches the wildcard - name generated by prepending the asterisk label to the closest - encloser. Furthermore, the bits corresponding to both QTYPE and - CNAME MUST NOT be set in the wildcard matching NSEC3 RR. - -8.8. Validating Wildcard Answer Responses - - The verified wildcard answer RRSet in the response provides the - validator with a (candidate) closest encloser for QNAME. This - closest encloser is the immediate ancestor to the generating - wildcard. - - Validators MUST verify that there is an NSEC3 RR that covers the - "next closer" name to QNAME present in the response. This proves - that QNAME itself did not exist and that the correct wildcard was - used to generate the response. - -8.9. Validating Referrals to Unsigned Subzones - - The delegation name in a referral is the owner name of the NS RRSet - present in the authority section of the referral response. - - If there is an NSEC3 RR present in the response that matches the - delegation name, then the validator MUST ensure that the NS bit is - set and that the DS bit is not set in the Type Bit Maps field of the - NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from - the correct (i.e., parent) zone. This is done by ensuring that the - SOA bit is not set in the Type Bit Maps field of this NSEC3 RR. - - Note that the presence of an NS bit implies the absence of a DNAME - bit, so there is no need to check for the DNAME bit in the Type Bit - Maps field of the NSEC3 RR. - - If there is no NSEC3 RR present that matches the delegation name, - then the validator MUST verify a closest provable encloser proof for - the delegation name. The validator MUST verify that the Opt-Out bit - is set in the NSEC3 RR that covers the "next closer" name to the - delegation name. - - -9. Resolver Considerations - - - - - -Laurie, et al. Expires July 5, 2007 [Page 25] - -Internet-Draft nsec3 January 2007 - - -9.1. NSEC3 Resource Record Caching - - Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs - when returning responses that contain them. In DNSSEC [RFC4035], in - many cases it is possible to find the correct NSEC RR to return in a - response by name (e.g., when returning a referral, the NSEC RR will - always have the same owner name as the delegation.) With this - specification, that will not be true, nor will a cache be able to - calculate the name(s) of the appropriate NSEC3 RR(s). - Implementations may need to use new methods for caching and - retrieving NSEC3 RRs. - -9.2. Use of the AD Bit - - The AD bit, as defined by [RFC4035], MUST NOT be set when returning a - response containing a closest (provable) encloser proof in which the - NSEC3 RR that covers the "next closer" name has the Opt-Out bit set. - - This rule is based on what this closest encloser proof actually - proves: names that would be covered by the Opt-Out NSEC3 RR may or - may not exist as insecure delegations. As such, not all the data in - responses containing such closest encloser proofs will have been - cryptographically verified, so the AD bit cannot be set. - - -10. Special Considerations - -10.1. Domain Name Length Restrictions - - Zones signed using this specification have additional domain name - length restrictions imposed upon them. In particular, zones with - names that, when converted into hashed owner names, exceed the 255 - octet length limit imposed by [RFC1035] cannot use this - specification. - - The actual maximum length of a domain name in a particular zone - depends on both the length of the zone name (versus the whole domain - name) and the particular hash function used. - -10.2. DNAME at the Zone Apex - - The DNAME specification [RFC2672] section 3 has a 'no-descendants' - limitation. If a DNAME RR is present at node N, there MUST be no - data at any descendant of N. - - If N is the apex of the zone, there will be NSEC3 and RRSIG types - present at descendants of N. This specification updates the DNAME - specification to allow NSEC3 and RRSIG types at descendants of the - - - -Laurie, et al. Expires July 5, 2007 [Page 26] - -Internet-Draft nsec3 January 2007 - - - apex regardless of the existence of DNAME at the apex. - -10.3. Iterations - - Setting the number of iterations used allows the zone owner to choose - the cost of computing a hash, and so the cost of generating a - dictionary. Note that this is distinct from the effect of salt, - which prevents the use of a single precomputed dictionary for all - time. - - Obviously the number of iterations also affects the zone owner's cost - of signing and serving the zone as well as the validator's cost of - verifying responses from the zone. We therefore impose an upper - limit on the number of iterations. We base this on the number of - iterations that approximates the cost of verifying an RRSet. - - The limits, therefore, are based on the size of the smallest zone - signing key, rounded up to the nearest table value (or rounded down - if the key is larger than the largest table value.) - - A zone owner MUST NOT use a value higher than shown in the table - below for iterations for the given key size. A resolver MAY treat a - response with a higher value as insecure, after the validator has - verified that the signature over the NSEC3 RR is correct. - - +--------------+------------+ - | RSA Key Size | Iterations | - +--------------+------------+ - | 1024 | 150 | - | 2048 | 500 | - | 4096 | 2,500 | - +--------------+------------+ - - +--------------+------------+ - | DSA Key Size | Iterations | - +--------------+------------+ - | 1024 | 1,500 | - | 2048 | 5,000 | - +--------------+------------+ - - This table is based on 150,000 SHA-1 calculations per second, 1000 - RSA verifications per second for 1024 bit keys, 300 verifications per - second for 2048 bit keys, 60 verifications per second for 4096 bit - keys, 100 DSA verifications per second for 1024 bit keys and 30 - verifications per second for 2048 bit keys. - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 27] - -Internet-Draft nsec3 January 2007 - - -10.4. Transitioning a Signed Zone from NSEC to NSEC3 - - When transitioning an already signed and trusted zone to this - specification, care must be taken to prevent client validation - failures during the process. - - The basic procedure is as follows: - - 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases - described in Section 2. The actual method for safely and - securely changing the DNSKEY RRSet of the zone is outside the - scope of this specification. However, the end result MUST be - that all DS RRs in the parent use the specified algorithm - aliases. - - After this transition is complete, all NSEC3-unaware clients will - treat the zone as insecure. At this point, the authoritative - server still returns negative and wildcard responses that contain - NSEC RRs. - - 2. Add signed NSEC3 RRs to the zone, either incrementally or all at - once. If adding incrementally, then the last RRSet added MUST be - the NSEC3PARAM RRSet. - - 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to - serving negative and wildcard responses with NSEC3 RRs according - to this specification. - - 4. Remove the NSEC RRs either incrementally or all at once. - -10.5. Transitioning a Signed Zone From NSEC3 to NSEC - - To safely transition back to a DNSSEC [RFC4035] signed zone, simply - reverse the procedure above: - - 1. Add NSEC RRs incrementally or all at once. - - 2. Remove the NSEC3PARAM RRSet. This will signal the server to use - the NSEC RRs for negative and wildcard responses. - - 3. Remove the NSEC3 RRs either incrementally or all at once. - - 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. - After this transition is complete, all NSEC3-unaware clients will - treat the zone as secure. - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 28] - -Internet-Draft nsec3 January 2007 - - -11. IANA Considerations - - This document updates the IANA registry "DOMAIN NAME SYSTEM - PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub- - registry "TYPES", by defining two new types. Section 3 defines the - NSEC3 RR type NN, (value 50 suggested). Section 4 defines the - NSEC3PARAM RR type MM (value 51 suggested). - - This document updates the IANA registry "DNS SECURITY ALGORITHM - NUMBERS - per [RFC4035]" - http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2 - defines the aliases DSA-NSEC3 (XX) and RSASHA1-NSEC3 (YY) for - respectively existing registrations DSA and RSASHA1. - - [### IMPORTANT RFC EDITOR INSTRUCTION: - - After the IANA allocation has been done the examples in the Appendix - will need to be updated. The signature generation algorithm includes - the requested RR types as input. - - The RFC editor should not edit the Appendices before the IANA - typecode has been assigned and the examples have been regenerated by - the editor.] - - Finally, this document creates a new IANA registry for NSEC3 hash - algorithms. This registry should be named "DNSSEC NSEC3 Hash - Algorithms". The initial contents of this registry are: - - 0 is Reserved - - 1 is SHA-1. - - 2-255 Available for assignment - - Assignment of additional NSEC3 hash algorithms in this registry - requires IETF Standards Action [RFC2434]. - - -12. Security Considerations - -12.1. Hashing Considerations - -12.1.1. Dictionary Attacks - - The NSEC3 RRs are still susceptible to dictionary attacks (i.e. the - attacker retrieves all the NSEC3 RRs, then calculates the hashes of - all likely domain names, comparing against the hashes found in the - NSEC3 RRs, and thus enumerating the zone). These are substantially - - - -Laurie, et al. Expires July 5, 2007 [Page 29] - -Internet-Draft nsec3 January 2007 - - - more expensive than enumerating the original NSEC RRs would have - been, and in any case, such an attack could also be used directly - against the name server itself by performing queries for all likely - names, though this would obviously be more detectable. The expense - of this off-line attack can be chosen by setting the number of - iterations in the NSEC3 RR. - - Zones are also susceptible to a pre-calculated dictionary attack -- - that is, a list of hashes for all likely names is computed once, then - NSEC3 RR is scanned periodically and compared against the precomputed - hashes. This attack is prevented by changing the salt on a regular - basis. - -12.1.2. Collisions - - Hash collisions between QNAME and the owner name of an NSEC3 RR may - occur. When they do, it will be impossible to prove the non- - existence of the colliding QNAME. However, with SHA-1, this is - highly unlikely (on the order of 1 in 2^160). Note that DNSSEC - already relies on the presumption that a cryptographic hash function - is second pre-image resistant, since these hash functions are used - for generating and validating signatures and DS RRs. - -12.1.3. Using New or Unknown Hash Algorithms - - Since validators are instructed to ignore NSEC3 RRs with unknown hash - algorithms, simply using a new or unknown hash algorithm directly - will lead to validation failures with clients that understand NSEC3 - but do not understand the hash algorithm. - - To prevent this, care must be taken to protect such clients. It is - suggested that a similar technique to the one being used in this - specification to protect older clients be employed (see Section 2.) - -12.1.4. Using High Iteration Values - - Since validators should treat responses containing NSEC3 RRs with - high iteration values as insecure, presence of just one signed NSEC3 - RR with a high iteration value in a zone provides attackers with a - possible downgrade attack. - - The attack is simply to remove any existing NSEC3 RRs from a - response, and replace or add a single (or multiple) NSEC3 RR that - uses a high iterations value to the response. Validators will then - be forced to treat the response as insecure. This attack would be - effective only when all of following conditions are met: - - - - - -Laurie, et al. Expires July 5, 2007 [Page 30] - -Internet-Draft nsec3 January 2007 - - - o There is at least one signed NSEC3 RR that uses a high iterations - value present in the zone. - - o The attacker has access to one or more of these NSEC3 RRs. This - is trivially true when the NSEC3 RRs with high iterations values - are being returned in typical responses, but may also be true if - the attacker can access the zone via AXFR or IXFR queries, or any - other methodology. - - Using a high number of iterations also introduces an additional - denial-of-service opportunity against servers, since servers must - calculate several hashes per negative or wildcard response. - -12.2. Opt-Out Considerations - - The Opt-Out Flag (O) allows for unsigned names, in the form of - delegations to unsigned zones, to exist within an otherwise signed - zone. All unsigned names are, by definition, insecure, and their - validity or existence cannot be cryptographically proven. - - In general: - - o Resource records with unsigned names (whether existing or not) - suffer from the same vulnerabilities as RRs in an unsigned zone. - These vulnerabilities are described in more detail in [RFC3833] - (note in particular sections 2.3, "Name Chaining" and 2.6, - "Authenticated Denial of Domain Names"). - - o Resource records with signed names have the same security whether - or not Opt-Out is used. - - Note that with or without Opt-Out, an insecure delegation may be - undetectably altered by an attacker. Because of this, the primary - difference in security when using Opt-Out is the loss of the ability - to prove the existence or nonexistence of an insecure delegation - within the span of an Opt-Out NSEC3 RR. - - In particular, this means that a malicious entity may be able to - insert or delete RRs with unsigned names. These RRs are normally NS - RRs, but this also includes signed wildcard expansions (while the - wildcard RR itself is signed, its expanded name is an unsigned name). - - Note that being able to add a delegation is functionally equivalent - to being able to add any RR type: an attacker merely has to forge a - delegation to name server under his/her control and place whatever - RRs needed at the subzone apex. - - While in particular cases, this issue may not present a significant - - - -Laurie, et al. Expires July 5, 2007 [Page 31] - -Internet-Draft nsec3 January 2007 - - - security problem, in general it should not be lightly dismissed. - Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. - In particular, zone signing tools SHOULD NOT default to using Opt- - Out, and MAY choose to not support Opt-Out at all. - -12.3. Other Considerations - - Walking the NSEC3 RRs will reveal the total number of RRs in the zone - (plus empty non-terminals), and also what types there are. This - could be mitigated by adding dummy entries, but certainly an upper - limit can always be found. - - -13. References - -13.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, - RFC 2929, September 2000. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - - - -Laurie, et al. Expires July 5, 2007 [Page 32] - -Internet-Draft nsec3 January 2007 - - - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, October 2006. - -13.2. Informative References - - [I-D.ietf-dnsext-dnssec-opt-in] - Blacka, D., "DNSSEC Opt-In", - draft-ietf-dnsext-dnssec-opt-in-09 (work in progress), - June 2006. - - [I-D.jas-dnsext-no] - Josefsson, S., "Authenticating denial of existence in DNS - with minimum disclosure", draft-jas-dnsext-no-00 (work in - progress), July 2000. - - [I-D.laurie-dnsext-nsec2v2] - Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", - draft-laurie-dnsext-nsec2v2-00 (work in progress), - December 2004. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain - Name System (DNS)", RFC 3833, August 2004. - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - - -Appendix A. Example Zone - - This is a zone showing its NSEC3 RRs. They can also be used as test - vectors for the hash algorithm. - - The overall TTL and class are specified in the SOA RR, and are - subsequently omitted for clarity. - - - -Laurie, et al. Expires July 5, 2007 [Page 33] - -Internet-Draft nsec3 January 2007 - - - [### RFC-editor: the examples below needs to be regenerated - once IANA has completed its allocations, the document - editors will supply the modified text ] - - example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) - RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - NS ns1.example. - NS ns2.example. - RRSIG NS 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM - gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 - JpiZcff2Cj2B0w== ) - MX 1 xx.example. - RRSIG MX 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - jsGuTpXTTrZHzUKnViUpJ8YyGNpDd6n/sy2g - HnSC0nj2jPxTC5VENLo3GxSpCSA5DlAz57p+ - RllUJk3DWktkjw== ) - DNSKEY 256 3 133 ( - AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU - 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL - ExXT48OGGdbfIme5 ) - DNSKEY 257 3 133 ( - AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX - cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 - zsYKWJ7BvR2894hX ) - RRSIG DNSKEY 133 1 3600 20150420235959 ( - 20051021000000 22088 example. - Xpo9ptByXb8M1JR1i0KuRmKGc/YeOLcc6Ptn - RJOx6ADLSL2mU6AYX5tAJRMTKTXk6waLIaxu - liqUBOkCjLUZMw== ) - NSEC3PARAM 1 0 12 aabbccdd - RRSIG NSEC3PARAM 133 1 3600 20150420235959 ( - 20051021000000 62827 example. - LIDOPjIUc2DtDpXUlOaLnJkHKbacDvXZlhRm - g4eFGnaEd794HnjRjeT9w5QwtLDpLyyMRbGt - 4L0XlqhGJCcAsA== ) - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - - - -Laurie, et al. Expires July 5, 2007 [Page 34] - -Internet-Draft nsec3 January 2007 - - - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - GtJTFlvT5eYaK3rNUPQjpCKoIefvWZxQrDxU - jYsmoIWdLOVOuD5ZSDDQA3anDctOHdA/XbXn - o2uyWso1OzVlgg== ) - NSEC3 1 1 12 aabbccdd ( - 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - MOyKYIjbWDwnme6WV5R9kY9WWCjTPxcjYo+c - vWgJRnmXYZtz0bYqqELIalZtHsT2W0BOtCxS - Y2gIduy/7FVk0g== ) - 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( - 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - oBio/cYM5olvRWV3zW+IToAT3mU0gqbU+gZu - 7VysaXXufogv2B0ciYH29jdrRjvcCadsy/5E - Yj/THQIqFXEdOw== ) - 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( - b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM - UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 - Si8JqvOk+TRYqA== ) - a.example. NS ns1.a.example. - NS ns2.a.example. - DS 58470 5 1 ( - 3079F1593EBAD6DC121E202A8B766A6A4837206C ) - RRSIG DS 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - qxw4j5LNe70UDu121YqAaqQjyjYbdKNd/4bE - nH0kjQswuiGs9EuArCBhcWocWQDBku+A4HMH - JdLqJr5p4JctLg== ) - ns1.a.example. A 192.0.2.5 - ns2.a.example. A 192.0.2.6 - ai.example. A 192.0.2.9 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag - lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 - BXfXAqURwLqznA== ) - HINFO "KLH-10" "ITS" - - - -Laurie, et al. Expires July 5, 2007 [Page 35] - -Internet-Draft nsec3 January 2007 - - - RRSIG HINFO 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - BuDv+No06VEcIsEnvBdjdKm6kxQGrhOgKEKb - Gsb8DJRjY7Lia+YG2//s6OlOIfxPmLlLiYpA - i3q2sEjTJhocGQ== ) - AAAA 2001:db8:0:0:0:0:f00:baa9 - RRSIG AAAA 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M - hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x - 2ruyuN0zC+PABA== ) - b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( - gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - E1RiKYSYiN2U5t1h29o63vWwg++iOyJxNhtp - K0FRNe1uc/ZMElEuSOl1mj7n7hoZExR4j7J4 - xDdGSZkZZ7Np+w== ) - c.example. NS ns1.c.example. - NS ns2.c.example. - ns1.c.example. A 192.0.2.7 - ns2.c.example. A 192.0.2.8 - gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( - ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA - RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - PC6xuuhgRizxo+NWTAL4BqOyRwGdjJNjdu7G - +s8PPW9M1/FObcnaxvrFqnKVIzIOIkD66U/K - 09DKQD9ILCfOlw== ) - ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( - k8udemvp1j2f7eg6jebps17vp3n8i58h ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - JbIr0ml7CyVwid1WyNbXlxmZ4s0ZPZOjSbQI - wZEky0ImECHZLpa9/dASklriA6Yg8lgUzsj4 - bJwVGJ6LFzD1fA== ) - k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( - kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - chrf07zCt7K33AE6ZeF4Ti7CtaGePugS+I8t - bEzAbluRk3BzLtCKxqDUFVl1FVgq8KrQPLgU - h7mwmVDRXopnDw== ) - kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( - q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - - - -Laurie, et al. Expires July 5, 2007 [Page 36] - -Internet-Draft nsec3 January 2007 - - - BHESCxzi1TT5+G1b5add7PkBqh+8UhIM2m4w - mrOam5jM443iKviA2oGTYtdawPB0xTIoHZe7 - SbrvmdDe+bjCNg== ) - ns1.example. A 192.0.2.1 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - ratEKfeWD/pJJHO/XqEINvOp3so7pn9Pphxn - fRiCOVsa527M/ucRcQqGYCF0CN4jAXhW+6BS - ZzT0om+VdioRmg== ) - ns2.example. A 192.0.2.2 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - mW/DJMbQyD5y5C+a70vWyIWZyQ+Xg1zzkWHX - w3jfqmePgpdJnMrpGOcRIpy5irCFWiCwTp2o - cPT+k0ccpxtkLQ== ) - q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( - r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 - tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu - W7Zo0HsSFJJLIw== ) - r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( - t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - OFXtK7DkTcIHFNeChJbdCgz5lX8ZOXVE4WeU - RGHgiz9VfmLiN18+S7ucSt/UXNhX2ZpYWchJ - FEmSZ39hZpTN0w== ) - t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA - RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - U7hZiI+Vxmcn9JLSxyOs0p4nf6+0ckmzLKX2 - hCte/8EVLibUfvzyN8sP1k4nIYmMfciwV+dB - 1HnaArgp+4wgOw== ) - *.w.example. MX 1 ai.example. - RRSIG MX 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR - c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq - a7Xfz/f9xzvSTw== ) - x.w.example. MX 1 xx.example. - RRSIG MX 133 3 3600 20150420235959 20051021000000 ( - 62827 example. - BLSDMos8kYR7+2U7iwwdqdhU82hzq0s57xtw - F08tWU/d19jrNO6LdWfBL/FJ8zL8ZpEjhh6b - - - -Laurie, et al. Expires July 5, 2007 [Page 37] - -Internet-Draft nsec3 January 2007 - - - 8cj0f5yQOUyShw== ) - x.y.w.example. MX 1 xx.example. - RRSIG MX 133 4 3600 20150420235959 20051021000000 ( - 62827 example. - GPzELyUCxrnyep8uMcqthUXjTqYBmgeaveb9 - 2vQgzUyPLLamNN/YqMHr6tGQNxeMAhclxUSQ - eoCggUBVhFfB1Q== ) - xx.example. A 192.0.2.10 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - Sz+fPqY8II1VDq+dY48Q40dq1aoBR2RAuhKg - QNKXEYcULtJo/hxxfEAkJSNBKU5QnHpnnT9L - jqaSdob7ZhdxHg== ) - HINFO "KLH-10" "TOPS-20" - RRSIG HINFO 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - YJFwmD0By0NpGEvO1nE1ZTH10XrmpKnVuAEI - cAxLLHyPs3qyGQdDEG7sQX5+PfiOGZrNmZef - 8NgQhW8kGEgN1Q== ) - AAAA 2001:db8:0:0:0:0:f00:baaa - RRSIG AAAA 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - VAJBlXoTOScrIM6yPlDsd9o05v39qIzFnemR - 2vgw1s4l8maJVWi9IHEg8oiypJvGwSCP1nFs - EOlXyNFQJ0fWGA== ) - - -Appendix B. Example Responses - - [### RFC-editor: the example below needs to be regenerated once IANA - has completed its allocations, the document editors will supply the - modified text ] - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1. Name Error - - An authoritative name error. The NSEC3 RRs prove that the name does - not exist and that there is no wildcard RR that should have been - expanded. - -;; Header: QR AA DO RCODE=3 -;; -;; Question -a.c.x.w.example. IN A - -;; Answer - - - -Laurie, et al. Expires July 5, 2007 [Page 38] - -Internet-Draft nsec3 January 2007 - - -;; (empty) - -;; Authority - -example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) -example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - -;; NSEC3 RR that covers the "next closer" name (c.x.w.example) -;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh - -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - - -;; NSEC3 RR that matches the closest encloser (x.w.example) -;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 - -b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( - gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) -b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - E1RiKYSYiN2U5t1h29o63vWwg++iOyJxNhtp - K0FRNe1uc/ZMElEuSOl1mj7n7hoZExR4j7J4 - xDdGSZkZZ7Np+w== ) - -;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example) -;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m - -35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( - b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) -35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM - UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 - Si8JqvOk+TRYqA== ) - -;; Additional - - - -Laurie, et al. Expires July 5, 2007 [Page 39] - -Internet-Draft nsec3 January 2007 - - -;; (empty) - - The query returned three NSEC3 RRs that prove that the requested data - does not exist and that no wildcard expansion applies. The negative - response is authenticated by verifying the NSEC3 RRs. The - corresponding RRSIGs indicate that the NSEC3 RRs are signed by an - "example" DNSKEY of algorithm 133 and with key tag 62827. The - resolver needs the corresponding DNSKEY RR in order to authenticate - this answer. - - One of the owner names of the NSEC3 RRs matches the closest encloser. - One of the NSEC3 RRs prove that there exists no longer name. One of - the NSEC3 RRs prove that there exists no wildcard RRSets that should - have been expanded. The closest encloser can be found by applying - the algorithm in section Section 8.3. - - In the above example, the name 'x.w.example' hashes to - 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might - be the closest encloser. To prove that 'c.x.w.example' and - '*.x.w.example' do not exist, these names are hashed to, - respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and - '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs - prove that these hashed owner names do not exist. - -B.2. No Data Error - - A "no data" response. The NSEC3 RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 40] - -Internet-Draft nsec3 January 2007 - - -;; Header: QR AA DO RCODE=0 -;; -;; Question -ns1.example. IN MX - -;; Answer -;; (empty) - -;; Authority -example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) -example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - -;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set. - -2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( - 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) -2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - MOyKYIjbWDwnme6WV5R9kY9WWCjTPxcjYo+c - vWgJRnmXYZtz0bYqqELIalZtHsT2W0BOtCxS - Y2gIduy/7FVk0g== ) -;; Additional -;; (empty) - - The query returned an NSEC3 RR that proves that the requested name - exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"), - but the requested RR type does not exist (type MX is absent in the - type code list of the NSEC3 RR), and was not a CNAME (type CNAME is - also absent in the type code list of the NSEC3 RR.) - -B.2.1. No Data Error, Empty Non-Terminal - - A "no data" response because of an empty non-terminal. The NSEC3 RR - proves that the name exists and that the requested RR type does not. - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 41] - -Internet-Draft nsec3 January 2007 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - y.w.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) - example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - - ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set. - - ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( - k8udemvp1j2f7eg6jebps17vp3n8i58h ) - ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - JbIr0ml7CyVwid1WyNbXlxmZ4s0ZPZOjSbQI - wZEky0ImECHZLpa9/dASklriA6Yg8lgUzsj4 - bJwVGJ6LFzD1fA== ) - - ;; Additional - ;; (empty) - - - The query returned an NSEC3 RR that proves that the requested name - exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"), - but the requested RR type does not exist (Type A is absent in the - Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty - non-terminal proof using NSECs, this is identical to a No Data Error. - This example is solely mentioned to be complete. - -B.3. Referral to an Opt-Out Unsigned Zone - - The NSEC3 RRs prove that nothing for this delegation was signed. - There is no proof that the unsigned delegation exists. - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 42] - -Internet-Draft nsec3 January 2007 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.c.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - c.example. NS ns1.c.example. - NS ns2.c.example. - - ;; NSEC3 RR that covers the "next closer" name (c.example) - ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck - - 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( - b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) - 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM - UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 - Si8JqvOk+TRYqA== ) - - ;; NSEC3 RR that matches the closest encloser (example) - ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom - - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - - ;; Additional - ns1.c.example. A 192.0.2.7 - ns2.c.example. A 192.0.2.8 - - - The query returned a referral to the unsigned "c.example." zone. The - response contains the closest provable encloser of "c.example" to be - "example", since the hash of "c.example" - ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR - and its Opt-Out bit is set. - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 43] - -Internet-Draft nsec3 January 2007 - - -B.4. Wildcard Expansion - - A query that was answered with a response containing a wildcard - expansion. The label count in the RRSIG RRSet in the answer section - indicates that a wildcard RRSet was expanded to produce this - response, and the NSEC3 RR proves that no "next closer" name exists - in the zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 44] - -Internet-Draft nsec3 January 2007 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. MX 1 ai.example. - a.z.w.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR - c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq - a7Xfz/f9xzvSTw== ) - - ;; Authority - example. NS ns1.example. - example. NS ns2.example. - example. RRSIG NS 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM - gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 - JpiZcff2Cj2B0w== ) - - ;; NSEC3 RR that covers the "next closer" name (z.w.example) - ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 - - q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( - r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) - q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 - tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu - W7Zo0HsSFJJLIw== ) - - ;; Additional - ai.example. A 192.0.2.9 - ai.example. RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag - lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 - BXfXAqURwLqznA== ) - ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9 - ai.example. RRSIG AAAA 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M - hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x - 2ruyuN0zC+PABA== ) - - - - - -Laurie, et al. Expires July 5, 2007 [Page 45] - -Internet-Draft nsec3 January 2007 - - - The query returned an answer that was produced as a result of - wildcard expansion. The answer section contains a wildcard RRSet - expanded as it would be in a traditional DNS response. The RRSIG - Labels field value of 2 indicates that the answer is the result of - wildcard expansion, as the "a.z.w.example" name contains 4 labels. - This also shows that "w.example" exists, so there is no need for an - NSEC3 RR that matches the closest encloser. - - The NSEC3 RR proves that no closer match could have been used to - answer this query. - -B.5. Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC3 RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) - example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - - ;; NSEC3 RR that matches the closest encloser (w.example) - ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h - - k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( - kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) - k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - chrf07zCt7K33AE6ZeF4Ti7CtaGePugS+I8t - bEzAbluRk3BzLtCKxqDUFVl1FVgq8KrQPLgU - h7mwmVDRXopnDw== ) - - ;; NSEC3 RR that covers the "next closer" name (z.w.example) - ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 - - - - -Laurie, et al. Expires July 5, 2007 [Page 46] - -Internet-Draft nsec3 January 2007 - - - q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( - r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) - q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 - tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu - W7Zo0HsSFJJLIw== ) - - ;; NSEC3 RR that matches a wildcard at the closest encloser. - ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en - - r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( - t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) - r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - OFXtK7DkTcIHFNeChJbdCgz5lX8ZOXVE4WeU - RGHgiz9VfmLiN18+S7ucSt/UXNhX2ZpYWchJ - FEmSZ39hZpTN0w== ) - - ;; Additional - ;; (empty) - - The query returned the NSEC3 RRs that prove that the requested data - does not exist and no wildcard RR applies. - -B.6. DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query that was mistakenly sent to - a name server for the child zone. - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 47] - -Internet-Draft nsec3 January 2007 - - -;; Header: QR AA DO RCODE=0 -;; -;; Question -example. IN DS - -;; Answer -;; (empty) - -;; Authority -example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) -example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - -;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set. - -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - -;; Additional -;; (empty) - - The query returned an NSEC3 RR showing that the requested was - answered by the server authoritative for the zone "example". The - NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3 - RR is from the apex of the child, not from the zone cut of the - parent. Queries for the "example" DS RRSet should be sent to the - parent servers (which are in this case the root servers). - - -Appendix C. Special Considerations - - The following paragraphs clarify specific behavior and explain - special considerations for implementations. - -C.1. Salting - - Augmenting original owner names with salt before hashing increases - the cost of a dictionary of pre-generated hash-values. For every bit - - - -Laurie, et al. Expires July 5, 2007 [Page 48] - -Internet-Draft nsec3 January 2007 - - - of salt, the cost of a precomputed dictionary doubles (because there - must be an entry for each word combined with each possible salt - value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of - salt, multiplying the cost by 2^2040. This means that an attacker - must, in practice, recompute the dictionary each time the salt is - changed. - - There MUST be at least one complete set of NSEC3 RRs for the zone - using the same salt value. - - The salt SHOULD be changed periodically to prevent pre-computation - using a single salt. It is RECOMMENDED that the salt be changed for - every re-signing. - - Note that this could cause a resolver to see RRs with different salt - values for the same zone. This is harmless, since each RR stands - alone (that is, it denies the set of owner names whose hashes, using - the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 - RR) - it is only the server that needs a complete set of NSEC3 RRs - with the same salt in order to be able to answer every possible - query. - - There is no prohibition with having NSEC3 RRs with different salts - within the same zone. However, in order for authoritative servers to - be able to consistently find covering NSEC3 RRs, the authoritative - server MUST choose a single set of parameters (algorithm, salt, and - iterations) to use when selecting NSEC3 RRs. - -C.2. Hash Collision - - Hash collisions occur when different messages have the same hash - value. The expected number of domain names needed to give a 1 in 2 - chance of a single collision is about 2^(n/2) for a hash of length n - bits (i.e. 2^80 for SHA-1). Though this probability is extremely - low, the following paragraphs deal with avoiding collisions and - assessing possible damage in the event of an attack using hash - collisions. - -C.2.1. Avoiding Hash Collisions During Generation - - During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occurring, an alternative salt - MUST be chosen and all hash values MUST be regenerated. - -C.2.2. Second Preimage Requirement Analysis - - A cryptographic hash function has a second-preimage resistance - property. The second-preimage resistance property means that it is - - - -Laurie, et al. Expires July 5, 2007 [Page 49] - -Internet-Draft nsec3 January 2007 - - - computationally infeasible to find another message with the same hash - value as a given message, i.e. given preimage X, to find a second - preimage X' != X such that hash(X) = hash(X'). The work factor for - finding a second preimage is of the order of 2^160 for SHA-1. To - mount an attack using an existing NSEC3 RR, an adversary needs to - find a second preimage. - - Assuming an adversary is capable of mounting such an extreme attack, - the actual damage is that a response message can be generated which - claims that a certain QNAME (i.e. the second pre-image) does exist, - while in reality QNAME does not exist (a false positive), which will - either cause a security aware resolver to re-query for the non- - existent name, or to fail the initial query. Note that the adversary - can't mount this attack on an existing name but only on a name that - the adversary can't choose and does not yet exist. - -C.2.3. Possible Hash Value Truncation Method - - The previous sections outlined the low probability and low impact of - a second-preimage attack. When impact and probability are low, while - space in a DNS message is costly, truncation is tempting. Truncation - might be considered to allow for shorter owner names and RDATA for - hashed labels. In general, if a cryptographic hash is truncated to n - bits, then the expected number of domains required to give a 1 in 2 - probability of a single collision is approximately 2^(n/2) and the - work factor to produce a second preimage is 2^n. - - An extreme hash value truncation would be truncating to the shortest - possible unique label value. This would be unwise, since the work - factor to produce second preimages would then approximate the size of - the zone (sketch of proof: if the zone has k entries, then the length - of the names when truncated down to uniqueness should be proportional - to log_2(k). Since the work factor to produce a second pre-image is - 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where - C is some constant), i.e. C'k - a work factor of k). - - Though the mentioned truncation can be maximized to a certain - extreme, the probability of collision increases exponentially for - every truncated bit. Given the low impact of hash value collisions - and limited space in DNS messages, the balance between truncation - profit and collision damage may be determined by local policy. Of - course, the size of the corresponding RRSIG RR is not reduced, so - truncation is of limited benefit. - - Truncation could be signaled simply by reducing the length of the - first label in the owner name. Note that there would have to be a - corresponding reduction in the length of the Next Hashed Owner Name - field. - - - -Laurie, et al. Expires July 5, 2007 [Page 50] - -Internet-Draft nsec3 January 2007 - - -Authors' Addresses - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - Phone: +44 20 8735 0686 - Email: ben@algroup.co.uk - - - Geoffrey Sisson - Nominet - Sandford Gate - Sandy Lane West - Oxford OX4 6LB - UNITED KINGDOM - - Phone: +44 1865 332211 - Email: geoff@nominet.org.uk - - - Roy Arends - Nominet - Sandford Gate - Sandy Lane West - Oxford OX4 6LB - UNITED KINGDOM - - Phone: +44 1865 332211 - Email: roy@nominet.org.uk - - - David Blacka - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: davidb@verisign.com - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 51] - -Internet-Draft nsec3 January 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Laurie, et al. Expires July 5, 2007 [Page 52] - - - - -Network Working Group B. Laurie -Internet-Draft G. Sisson -Intended status: Standards Track R. Arends -Expires: July 5, 2007 Nominet - D. Blacka - VeriSign, Inc. - January 2007 - - - DNSSEC Hashed Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-10 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 5, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - The Domain Name System Security Extensions (DNSSEC) introduced the - NSEC resource record (RR) for authenticated denial of existence. - This document introduces an alternative resource record, NSEC3, which - similarly provides authenticated denial of existence. However, it - also provides measures against zone enumeration and permits gradual - - - -Laurie, et al. Expires July 5, 2007 [Page 1] - -Internet-Draft nsec3 January 2007 - - - expansion of delegation-centric zones. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 5 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 - 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 8 - 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8 - 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9 - 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9 - 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 10 - 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 10 - 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 11 - 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 12 - 4. The NSEC3PARAM Record . . . . . . . . . . . . . . . . . . . . 12 - 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 13 - 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13 - 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 14 - 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14 - 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 15 - 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7. Authoritative Server Considerations . . . . . . . . . . . . . 16 - 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16 - 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18 - 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19 - 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19 - 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19 - 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 20 - 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20 - 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20 - 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20 - 7.2.9. Server Response to a Run-time Collision . . . . . . . 21 - 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21 - 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21 - - - -Laurie, et al. Expires July 5, 2007 [Page 2] - -Internet-Draft nsec3 January 2007 - - - 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21 - 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23 - 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23 - 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23 - 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23 - 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24 - 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24 - 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24 - 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25 - 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25 - 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25 - 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25 - 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26 - 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26 - 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26 - 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26 - 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26 - 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27 - 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28 - 10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 29 - 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 29 - 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30 - 12.1.3. Using New or Unknown Hash Algorithms . . . . . . . . . 30 - 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 30 - 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 31 - 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 - Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 33 - Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 38 - B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 38 - B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 40 - B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 41 - B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 42 - B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 44 - B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46 - B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 47 - Appendix C. Special Considerations . . . . . . . . . . . . . . . 48 - C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 48 - C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49 - C.2.1. Avoiding Hash Collisions During Generation . . . . . . 49 - C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 49 - C.2.3. Possible Hash Value Truncation Method . . . . . . . . 50 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 - - - -Laurie, et al. Expires July 5, 2007 [Page 3] - -Internet-Draft nsec3 January 2007 - - - Intellectual Property and Copyright Statements . . . . . . . . . . 52 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 4] - -Internet-Draft nsec3 January 2007 - - -1. Introduction - -1.1. Rationale - - The DNS Security Extensions included the NSEC RR to provide - authenticated denial of existence. Though the NSEC RR meets the - requirements for authenticated denial of existence, it introduces a - side-effect in that the contents of a zone can be enumerated. This - property introduces undesired policy issues. - - An enumerated zone can be used, for example, as a source of probable - e-mail addresses for spam, or as a key for multiple WHOIS queries to - reveal registrant data which many registries may have legal - obligations to protect. Many registries therefore prohibit copying - of their zone data; however, the use of NSEC RRs renders these - policies unenforceable. - - A second problem is that the cost to cryptographically secure - delegations to unsigned zones is high for large delegation-centric - zones and zones where insecure delegations will be updated rapidly. - For these zones, the costs of maintaining the NSEC RR chain may be - extremely high relative to the gain of cryptographically - authenticating existence of unsecured zones. - - This document presents the NSEC3 Resource Record which can be used as - an alternative to NSEC to mitigate these issues. - - Earlier work to address these issues include [I-D.jas-dnsext-no], - [I-D.ietf-dnsext-dnssec-opt-in] and [I-D.laurie-dnsext-nsec2v2]. - -1.2. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -1.3. Terminology - - The reader is assumed to be familiar with the basic DNS and DNSSEC - concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], - [RFC4035] and subsequent RFCs that update them: [RFC2136], [RFC2181] - and [RFC2308]. - - The following terminology is used throughout this document: - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 5] - -Internet-Draft nsec3 January 2007 - - - Zone enumeration: the practice of discovering the full content of a - zone via successive queries. Zone enumeration was non-trivial - prior to the introduction of DNSSEC. - - Original owner name: the owner name corresponding to a hashed owner - name. - - Hashed owner name: the owner name created after applying the hash - function to an owner name. - - Hash order: the order in which hashed owner names are arranged - according to their numerical value, treating the leftmost (lowest - numbered) octet as the most significant octet. Note that this - order is the same as the canonical DNS name order specified in - [RFC4034] when the hashed owner names are in base32 encoded with - Extended Hex Alphabet [RFC4648]. - - Empty non-terminal: a domain name that owns no resource records, but - has one or more subdomains that do. - - Delegation: an NS RRSet with a name different from the current zone - apex (non-zone-apex), signifying a delegation to a child zone. - - Secure delegation: a name containing a delegation (NS RRSet), and a - signed DS RRSet, signifying a delegation to a signed child zone. - - Insecure delegation: a name containing a delegation (NS RRSet), but - lacking a DS RRSet, signifying a delegation to an unsigned child - zone. - - Opt-Out NSEC3 resource record: an NSEC3 resource record which has - the Opt-Out flag set to 1. - - Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR. - - Closest encloser: the longest existing ancestor of a name. See also - section 3.3.1 of [RFC4592]. - - Closest provable encloser: the longest ancestor of a name that can - be proven to exist. Note that this is only different from the - closest encloser in an Opt-Out zone. - - Next closer name: the name one label longer than the closest - provable encloser of a name. - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 6] - -Internet-Draft nsec3 January 2007 - - - Base32: the "Base 32 Encoding with Extended Hex Alphabet" as - specified in [RFC4648]. Note that trailing padding characters - ("=") are not used in the NSEC3 specification. - - To cover: An NSEC3 RR is said to "cover" a name if the hash of the - name or "next closer" name falls between the owner name and the - next hashed owner name of the NSEC3. In other words, if it proves - the nonexistence of the name, either directly or by proving the - nonexistence of an ancestor of the name. - - To match: An NSEC3 RR is said to "match" a name if the owner name of - the NSEC3 RR is the same as the hashed owner name of that name. - - -2. Backwards Compatibility - - This specification describes a protocol change that is not generally - backwards compatible with [RFC4033], [RFC4034] and [RFC4035]. In - particular, security-aware resolvers that are unaware of this - specification (NSEC3-unaware resolvers) may fail to validate the - responses introduced by this document. - - In order to aid deployment, this specification uses a signaling - technique to prevent NSEC3-unaware resolvers from attempting to - validate responses from NSEC3-signed zones. - - This specification allocates two new DNSKEY algorithm identifiers for - this purpose. Algorithm XX, DSA-NSEC3 [### RFC-editor update - required, temporarily, XX=131] is an alias for algorithm 3, DSA. - Algorithm YY, RSASHA1-NSEC3 [### RFC-editor update required, - temporarily, YY=133] is an alias for algorithm 5, RSASHA1. These are - not new algorithms, they are simply additional identifiers for the - existing algorithms. - - Zones signed according to this specification MUST only use these - algorithm identifiers for their DNSKEY RRs. Because these new - identifiers will be unknown algorithms to existing, NSEC3-unaware - resolvers, those resolvers will then treat responses from the NSEC3 - signed zone as insecure, as detailed in [RFC4035], section 5.2. - - Security aware resolvers that are aware of this specification MUST - recognize the new algorithm identifiers and treat them as equivalent - to the algorithms that they alias. - - A methodology for transitioning from a DNSSEC signed zone to a zone - signed using NSEC3 is discussed in Section 10.4. - - - - - -Laurie, et al. Expires July 5, 2007 [Page 7] - -Internet-Draft nsec3 January 2007 - - -3. The NSEC3 Resource Record - - The NSEC3 Resource Record (RR) provides authenticated denial of - existence for DNS Resource Record Sets. - - The NSEC3 RR lists RR types present at the original owner name of the - NSEC3 RR. It includes the next hashed owner name in the hash order - of the zone. The complete set of NSEC3 RRs in a zone indicates which - RRSets exist for the original owner name of the RR and form a chain - of hashed owner names in the zone. This information is used to - provide authenticated denial of existence for DNS data. To provide - protection against zone enumeration, the owner names used in the - NSEC3 RR are cryptographic hashes of the original owner name - prepended as a single label to the name of the zone. The NSEC3 RR - indicates which hash function is used to construct the hash, which - salt is used, and how many iterations of the hash function are - performed over the original owner name. The hashing technique is - described fully in Section 5. - - Hashed owner names of unsigned delegations may be excluded from the - chain. An NSEC3 RR whose span covers the hash of an owner name or - "next closer" name of an unsigned delegation is referred to as an - Opt-Out NSEC3 RR and is indicated by the presence of a flag. - - The owner name for the NSEC3 RR is the base32 encoding of the hashed - owner name prepended as a single label to the name of the zone. - - The type value for the NSEC3 RR is NN. [### RFC-editor update - required, temporarily, NN=65324.] - - The NSEC3 RR RDATA format is class independent and is described - below. - - The class MUST be the same as the class of the original owner name. - - The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -3.1. RDATA Fields - -3.1.1. Hash Algorithm - - The Hash Algorithm field identifies the cryptographic hash algorithm - used to construct the hash-value. - - The values for this field are defined in the NSEC3 hash algorithm - registry, described in Section 11. - - - - -Laurie, et al. Expires July 5, 2007 [Page 8] - -Internet-Draft nsec3 January 2007 - - -3.1.2. Flags - - The Flags field contains 8 one-bit flags that can be used to indicate - different processing. All undefined flags must be zero. The only - flag defined by this specification is the Opt-Out flag. - -3.1.2.1. Opt-Out Flag - - The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned - delegations. It is the least significant bit in the Flags field. - See Section 6 for details about the use of this flag. - -3.1.3. Iterations - - The Iterations field defines the number of additional times the hash - function has been performed. More iterations result in greater - resiliency of the hash value against dictionary attacks, but at a - higher computational cost for both the server and resolver. See - Section 5 for details of the use of this field, and Section 10.3 for - limitations on the value. - -3.1.4. Salt Length - - The Salt Length field defines the length of the Salt field in octets, - ranging in value from 0 to 255. - -3.1.5. Salt - - The Salt field is appended to the original owner name before hashing - in order to defend against pre-calculated dictionary attacks. See - Section 5 for details on how the salt is used. - -3.1.6. Hash Length - - The Hash Length field defines the length of the Next Hashed Owner - Name field, ranging in value from 1 to 255 octets. - -3.1.7. Next Hashed Owner Name - - The Next Hashed Owner Name field contains the next hashed owner name - in hash order. This value is in binary format. Given the ordered - set of all hashed owner names, the Next Hashed Owner Name field - contains the hash of an owner name that immediately follows the owner - name of the given NSEC3 RR. The value of the Next Hashed Owner Name - field in the last NSEC3 RR in the zone is the same as the hashed - owner name of the first NSEC3 RR in the zone in hash order. Note - that, unlike the owner name of the NSEC3 RR, the value of this field - does not contain the appended zone name. - - - -Laurie, et al. Expires July 5, 2007 [Page 9] - -Internet-Draft nsec3 January 2007 - - -3.1.8. Type Bit Maps - - The Type Bit Maps field identifies the RRSet types which exist at the - original owner name of the NSEC3 RR. - -3.2. NSEC3 RDATA Wire Format - - The RDATA of the NSEC3 RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Alg. | Flags | Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Length | Next Hashed Owner Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Hash Algorithm is a single octet. - - Flags field is a single octet, the Opt-Out flag is the least - significant bit, as shown below: - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - | |O| - +-+-+-+-+-+-+-+-+ - - Iterations is represented as a 16-bit unsigned integer, with the most - significant bit first. - - Salt Length is represented as an unsigned octet. Salt Length - represents the length of the Salt field in octets. If the value is - zero, the following Salt field is omitted. - - Salt, if present, is encoded as a sequence of binary octets. The - length of this field is determined by the preceding Salt Length - field. - - Hash Length is represented as an unsigned octet. Hash Length - represents the length of the Next Hashed Owner Name field in octets. - - The next hashed owner name is not base32 encoded, unlike the owner - name of the NSEC3 RR. It is the unmodified binary hash value. It - does not include the name of the containing zone. The length of this - - - -Laurie, et al. Expires July 5, 2007 [Page 10] - -Internet-Draft nsec3 January 2007 - - - field is determined by the preceding Hash Length field. - -3.2.1. Type Bit Maps Encoding - - The encoding of the Type Bit Maps field is the same as that used by - the NSEC RR, described in [RFC4034]. It is explained and clarified - here for clarity. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the bitmap of the - window block, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC3 RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRSet of that type is present for the - original owner name of the NSEC3 RR. If a bit is set to 0, it - indicates that no RRSet of that type is present for the original - owner name of the NSEC3 RR. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in [RFC2929] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of the bitmap of - each block is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - original owner name of the NSEC3 RR. Trailing octets not specified - MUST be interpreted as zero octets. - - - - -Laurie, et al. Expires July 5, 2007 [Page 11] - -Internet-Draft nsec3 January 2007 - - -3.3. Presentation Format - - The presentation format of the RDATA portion is as follows: - - o The Hash Algorithm field is represented as an unsigned decimal - integer. The value has a maximum of 255. - - o The Flags field is represented as an unsigned decimal integer. - The value has a maximum of 255. - - o The Iterations field is represented as an unsigned decimal - integer. The value is between 0 and 65535, inclusive. - - o The Salt Length field is not represented. - - o The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the - sequence. The Salt field is represented as "-" (without the - quotes) when the Salt Length field has value 0. - - o The Hash Length field is not represented. - - o The Next Hashed Owner Name field is represented as an unpadded - sequence of case-insensitive base32 digits, without whitespace. - - o The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE - representation as described in [RFC3597] (section 5) MUST be used. - - -4. The NSEC3PARAM Record - - The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, - flags, iterations and salt) needed to calculate hashed owner names. - The presence of an NSEC3PARAM RR at a zone apex indicates that the - specified parameters may be used by authoritative servers to choose - an appropriate set of NSEC3 RRs for negative responses. - - If an NSEC3PARAM RR is present at the apex of a zone with a Flags - field value of zero, then there MUST be an NSEC3 using the same hash - algorithm, iterations and salt parameters present at every hashed - owner name in the zone. That is, the zone MUST contain a complete - set of NSEC3 RRs with the same hash algorithm, iterations and salt - parameters. - - The owner name for the NSEC3PARAM RR is the name of the zone apex. - - The type value for the NSEC3PARAM RR is MM. [### RFC-editor update - - - -Laurie, et al. Expires July 5, 2007 [Page 12] - -Internet-Draft nsec3 January 2007 - - - required, temporarily, MM=65325.] - - The NSEC3PARAM RR RDATA format is class independent and is described - below. - - The class MUST be the same as the NSEC3 RRs to which this RR refers. - -4.1. RDATA Fields - - The RDATA for this RR mirrors the first four fields in the NSEC3 RR. - -4.1.1. Hash Algorithm - - The Hash Algorithm field identifies the cryptographic hash algorithm - used to construct the hash-value. - - The acceptable values are the same as the corresponding field in the - NSEC3 RR. - -4.1.2. Flag Fields - - The Opt-Out flag is not used and is set to zero. - - All other flags reserved are for future use, and must be zero. - - NSEC3PARAM RRs with a Flags field value other than zero MUST be - ignored. - -4.1.3. Iterations - - The Iterations field defines the number of additional times the hash - is performed. - - Its acceptable values are the same as the corresponding field in the - NSEC3 RR. - -4.1.4. Salt Length - - The Salt Length field defines the length of the salt in octets, - ranging in value from 0 to 255. - -4.1.5. Salt - - The Salt field is appended to the original owner name before hashing. - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 13] - -Internet-Draft nsec3 January 2007 - - -4.2. NSEC3PARAM RDATA Wire Format - - The RDATA of the NSEC3PARAM RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Alg. | Flags | Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Hash Algorithm is a single octet. - - Flags field is a single octet. - - Iterations is represented as a 16-bit unsigned integer, with the most - significant bit first. - - Salt Length is represented as an unsigned octet. Salt Length - represents the length of the following Salt field in octets. If the - value is zero, the Salt field is omitted. - - Salt, if present, is encoded as a sequence of binary octets. The - length of this field is determined by the preceding Salt Length - field. - -4.3. Presentation Format - - The presentation format of the RDATA portion is as follows: - - o The Hash Algorithm field is represented as an unsigned decimal - integer. The value has a maximum of 255. - - o The Flags field is represented as an unsigned decimal integer. - The value has a maximum value of 255. - - o The Iterations field is represented as an unsigned decimal - integer. The value is between 0 and 65535, inclusive. - - o The Salt Length field is not represented. - - o The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the - sequences. This field is represented as "-" (without the quotes) - when the Salt Length field is zero. - - - - - -Laurie, et al. Expires July 5, 2007 [Page 14] - -Internet-Draft nsec3 January 2007 - - -5. Calculation of the Hash - - The hash calculation uses three of the NSEC3 RDATA fields: Hash - Algorithm, Salt, and Iterations. - - Define H(x) to be the hash of x using the Hash Algorithm selected by - the NSEC3 RR, k to be the number of Iterations, and || to indicate - concatenation. Then define: - - IH(salt, x, 0) = H(x || salt), and - - IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0 - - Then the calculated hash of an owner name is - - IH(salt, owner name, iterations), - - where the owner name is in the canonical form, defined as: - - The wire format of the owner name where: - - 1. The owner name is fully expanded (no DNS name compression) and - fully qualified; - - 2. All uppercase US-ASCII letters are replaced by the corresponding - lowercase US-ASCII letters; - - 3. If the owner name is a wildcard name, the owner name is in its - original unexpanded form, including the "*" label (no wildcard - substitution); - - This form is as defined in section 6.2 of [RFC4034]. - - -6. Opt-Out - - In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS - RRSets at delegation points are not signed and may be accompanied by - a DS RRSet. With the Opt-Out bit clear, the security status of the - child zone is determined by the presence or absence of this DS RRSet, - cryptographically proven by the signed NSEC3 RR at the hashed owner - name of the delegation. Setting the Opt-Out flag modifies this by - allowing insecure delegations to exist within the signed zone without - a corresponding NSEC3 RR at the hashed owner name of the delegation. - - An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the - owner name or "next closer" name of the delegation is between the - owner name of the NSEC3 RR and the next hashed owner name. - - - -Laurie, et al. Expires July 5, 2007 [Page 15] - -Internet-Draft nsec3 January 2007 - - - An Opt-Out NSEC3 RR does not assert the existence or non-existence of - the insecure delegations that it may cover. This allows for the - addition or removal of these delegations without recalculating or re- - signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do - assert the (non)existence of other, authoritative RRSets. - - An Opt-Out NSEC3 RR MAY have the same original owner name as an - insecure delegation. In this case, the delegation is proven insecure - by the lack of a DS bit in the type map and the signed NSEC3 RR does - assert the existence of the delegation. - - Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and - non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT - be any hashed owner names of insecure delegations (nor any other RRs) - between it and the name indicated by the next hashed owner name in - the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner - names or hashed "next closer" names of insecure delegations. - - The effects of the Opt-Out flag on signing, serving, and validating - responses are covered in following sections. - - -7. Authoritative Server Considerations - -7.1. Zone Signing - - Zones using NSEC3 must satisfy the following properties: - - o Each owner name within the zone that owns authoritative RRSets - MUST have a corresponding NSEC3 RR. Owner names that correspond - to unsigned delegations MAY have a corresponding NSEC3 RR. - However, if there is not a corresponding NSEC3 RR, there MUST be - an Opt-Out NSEC3 RR that covers the "next closer" name to the - delegation. Other non-authoritative RRs are not represented by - NSEC3 RRs. - - o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless - the empty non-terminal is only derived from an insecure delegation - covered by an Opt-Out NSEC3 RR. - - o The TTL value for any NSEC3 RR SHOULD be the same as the minimum - TTL value field in the zone SOA RR. - - o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST - indicate the presence of all types present at the original owner - name, except for the types solely contributed by an NSEC3 RR - itself. Note that this means that the NSEC3 type itself will - never be present in the Type Bit Maps. - - - -Laurie, et al. Expires July 5, 2007 [Page 16] - -Internet-Draft nsec3 January 2007 - - - The following steps describe a method of proper construction of NSEC3 - RRs. This is not the only such possible method. - - 1. For each unique original owner name in the zone add an NSEC3 RR. - - * If Opt-Out is being used, owner names of unsigned delegations - MAY be excluded. - - * The owner name of the NSEC3 RR is the hash of the original - owner name, prepended as a single label to the zone name. - - * The Next Hashed Owner Name field is left blank for the moment. - - * If Opt-Out is being used, set the Opt-Out bit to one. - - * For collision detection purposes, optionally keep track of the - original owner name with the NSEC3 RR. - - * Additionally, for collision detection purposes, optionally - create an additional NSEC3 RR corresponding to the original - owner name with the asterisk label prepended (i.e., as if a - wildcard existed as a child of this owner name) and keep track - of this original owner name. Mark this NSEC3 RR as temporary. - - 2. For each RRSet at the original owner name, set the corresponding - bit in the Type Bit Maps field. - - 3. If the difference in number of labels between the apex and the - original owner name is greater than 1, additional NSEC3 RRs need - to be added for every empty non-terminal between the apex and the - original owner name. This process may generate NSEC3 RRs with - duplicate hashed owner names. Optionally, for collision - detection, track the original owner names of these NSEC3 RRs and - create temporary NSEC3 RRs for wildcard collisions in a similar - fashion to step 1. - - 4. Sort the set of NSEC3 RRs into hash order. - - 5. Combine NSEC3 RRs with identical hashed owner names by replacing - them with a single NSEC3 RR with the Type Bit Maps field - consisting of the union of the types represented by the set of - NSEC3 RRs. If the original owner name was tracked, then - collisions may be detected when combining, as all of the matching - NSEC3 RRs should have the same original owner name. Discard any - possible temporary NSEC3 RRs. - - 6. In each NSEC3 RR, insert the next hashed owner name by using the - value of the next NSEC3 RR in hash order. The next hashed owner - - - -Laurie, et al. Expires July 5, 2007 [Page 17] - -Internet-Draft nsec3 January 2007 - - - name of the last NSEC3 RR in the zone contains the value of the - hashed owner name of the first NSEC3 RR in the hash order. - - 7. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, - Iterations and Salt fields to the zone apex. - - If a hash collision is detected, then a new salt has to be chosen and - the signing process restarted. - -7.2. Zone Serving - - This specification modifies DNSSEC-enabled DNS responses generated by - authoritative servers. In particular, it replaces the use of NSEC - RRs in such responses with NSEC3 RRs. - - In the following response cases, the NSEC RRs dictated by DNSSEC - [RFC4035] are replaced with NSEC3 RRs that prove the same facts. - Responses that would not contain NSEC RRs are unchanged by this - specification. - - When returning responses containing multiple NSEC3 RRs, all of the - NSEC3 RRs MUST use the same hash algorithm, iteration, and salt - values. The Flags field value MUST be either zero or one. - -7.2.1. Closest Encloser Proof - - For many NSEC3 responses a proof of the closest encloser is required. - This is a proof that some ancestor of the QNAME is the closest - encloser of QNAME. - - This proof consists of (up to) two different NSEC3 RRs: - - o An NSEC3 RR that matches the closest (provable) encloser. - - o An NSEC3 RR that covers the "next closer" name to the closest - encloser. - - The first NSEC3 RR essentially proposes a possible closest encloser, - and proves that the particular encloser does, in fact, exist. The - second NSEC3 RR proves that the possible closest encloser is the - closest, and proves that QNAME (and any ancestors between QNAME and - the closest encloser) do not exist. - - These NSEC3 RRs are collectively referred to as the "closest encloser - proof" in the subsequent descriptions. - - For example, the closest encloser proof for the nonexistent - "alpha.beta.gamma.example." owner name might prove that - - - -Laurie, et al. Expires July 5, 2007 [Page 18] - -Internet-Draft nsec3 January 2007 - - - "gamma.example." is the closest encloser. This response would - contain the NSEC3 RR that matches "gamma.example.", and would also - contain the NSEC3 RR that covers "beta.gamma.example." (which is the - "next closer" name.) - - It is possible, when using Opt-Out (Section 6), to not be able to - prove the actual closest encloser because it is, or is part of an - insecure delegation covered by an Opt-Out span. In this case, - instead of proving the actual closest encloser, the closest provable - encloser is used. That is, the closest enclosing authoritative name - is used instead. In this case, the set of NSEC3 RRs used for this - proof is referred to as the "closest provable encloser proof." - -7.2.2. Name Error Responses - - To prove the nonexistence of QNAME a closest encloser proof and an - NSEC3 RR covering the (nonexistent) wildcard RR at the closest - encloser MUST be included in the response. This collection of (up - to) three NSEC3 RRs proves both that QNAME does not exist and that a - wildcard that could have matched QNAME also does not exist. - - For example, if "gamma.example." is the closest provable encloser to - QNAME, then a NSEC3 RR covering "*.gamma.example." is included in the - authority section of the response. - -7.2.3. No Data Responses, QTYPE is not DS - - The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 - RR MUST NOT have the bits corresponding to either the QTYPE or CNAME - set in its Type Bit Maps field. - -7.2.4. No Data Responses, QTYPE is DS - - If there is an NSEC3 RR that matches QNAME, the server MUST return it - in the response. The bits corresponding with DS and CNAME MUST NOT - be set in the Type Bit Maps field of this NSEC3 RR. - - If no NSEC3 RR matches QNAME, the server MUST return a closest - provable encloser proof for QNAME. The NSEC3 RR that covers the - "next closer" name MUST have the Opt-Out bit set (note that this is - true by definition - if the Opt-Out bit is not set, something has - gone wrong). - - If a server is authoritative for both sides of a zone cut at QNAME, - the server MUST return the proof from the parent side of the zone - cut. - - - - - -Laurie, et al. Expires July 5, 2007 [Page 19] - -Internet-Draft nsec3 January 2007 - - -7.2.5. Wildcard No Data Responses - - If there is a wildcard match for QNAME, but QTYPE is not present at - that name, the response MUST include a closest encloser proof for - QNAME and MUST include the NSEC3 RR that matches the wildcard. This - combination proves both that QNAME itself does not exist and that a - wildcard that matches QNAME does exist. Note that the closest - encloser to QNAME MUST be the immediate ancestor of the wildcard RR - (if this is not the case, then something has gone wrong). - -7.2.6. Wildcard Answer Responses - - If there is a wildcard match for QNAME and QTYPE, then, in addition - to the expanded wildcard RRSet returned in the answer section of the - response, proof that the wildcard match was valid must be returned. - - This proof is accomplished by proving that both QNAME does not exist, - and that the closest encloser of the QNAME and the immediate ancestor - of the wildcard are the same (i.e., the correct wildcard matched). - - To this end, the NSEC3 RR that covers the "next closer" name of the - immediate ancestor of the wildcard MUST be returned. It is not - necessary to return an NSEC3 RR that matches the closest encloser, as - the existence of this closest encloser is proven by the presence of - the expanded wildcard in the response. - -7.2.7. Referrals to Unsigned Subzones - - If there is an NSEC3 RR that matches the delegation name, then that - NSEC3 RR MUST be included in the response. The DS bit in the type - bit maps of the NSEC3 RR MUST NOT be set. - - If the zone is Opt-Out, then there may not be an NSEC3 RR - corresponding to the delegation. In this case, the closest provable - encloser proof MUST be included in the response. The included NSEC3 - RR that covers the "next closer" name for the delegation MUST have - the Opt-Out flag set to one. (Note that this will be the case unless - something has gone wrong). - -7.2.8. Responding to Queries for NSEC3 Owner Names - - The owner names of NSEC3 RRs are not represented in the NSEC3 RR - chain like other owner names. As a result, each NSEC3 owner name is - covered by another NSEC3 RR, effectively negating the existence of - the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR - can be proven by its RRSIG RRSet. - - If the following conditions are all true: - - - -Laurie, et al. Expires July 5, 2007 [Page 20] - -Internet-Draft nsec3 January 2007 - - - o The QNAME equals the owner name of an existing NSEC3 RR, and - - o No RR types exist at the QNAME, nor at any descendant of QNAME. - - Then the response MUST be constructed as a Name Error response - (Section 7.2.2). Or, in other words, the authoritative name server - will act, as if the owner name of the NSEC3 RR did not exist. - - Note that NSEC3 RRs are returned as a result of an AXFR or IXFR - query. - -7.2.9. Server Response to a Run-time Collision - - If the hash of a non-existing QNAME collides with the owner name of - an existing NSEC3 RR, then the server will be unable to return a - response that proves that QNAME does not exist. In this case, the - server MUST return a response with an RCODE of 2 (server failure). - - Note that with the hash algorithm specified in this document, SHA-1, - such collisions are highly unlikely. - -7.3. Secondary Servers - - Secondary servers (and perhaps other entities) need to reliably - determine which NSEC3 parameters (i.e., hash, salt and iterations) - are present at every hashed owner name, in order to be able to choose - an appropriate set of NSEC3 RRs for negative responses. This is - indicated by an NSEC3PARAM RR present at the zone apex. - - If there are multiple NSEC3PARAM RRs present, there are multiple - valid NSEC3 chains present. The server must choose one of them, but - may use any criteria to do so. - -7.4. Zones Using Unknown Hash Algorithms - - Zones that are signed according to this specification, but are using - an unrecognized NSEC3 hash algorithm value, cannot be effectively - served. Such zones SHOULD be rejected when loading. Servers SHOULD - respond with RCODE=2 (server failure) responses when handling queries - that would fall under such zones. - -7.5. Dynamic Update - - A zone signed using NSEC3 may accept dynamic updates [RFC2136]. - However, NSEC3 introduces some special considerations for dynamic - updates. - - Adding and removing names in a zone MUST account for the creation or - - - -Laurie, et al. Expires July 5, 2007 [Page 21] - -Internet-Draft nsec3 January 2007 - - - removal of empty non-terminals. - - o When removing a name with a corresponding NSEC3, checks must be - made to remove any NSEC3 RRs corresponding with possible empty - non-terminals created by the name. Note that more than one name - may be asserting the existence of a particular empty non-terminal. - - o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs - MUST also be added for any empty non-terminals that are created. - That is, if there is not an existing NSEC3 RR matching an empty - non-terminal, it must be created and added. - - The presence of Opt-Out in a zone means that some additions or - delegations of names will not require changes to the NSEC3 RRs in a - zone. - - o When removing a delegation RRSet, if that delegation does not have - a matching NSEC3 RR, then it was opted out. In this case, nothing - further needs to be done. - - o When adding a delegation RRSet, if the "next closer" name of the - delegation is covered by an existing Opt-Out NSEC3 RR, then the - delegation MAY be added without modifying the NSEC3 RRs in the - zone. - - The presence of Opt-Out in a zone means that when adding or removing - NSEC3 RRs, the value of the Opt-Out flag that should be set in new or - modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of - basic rules to resolve the ambiguity. - - The central concept to these rules is that the state of the Opt-Out - flag of the covering NSEC3 RR is preserved. - - o When removing an NSEC3 RR, the value of the Opt-Out flag for the - previous NSEC3 RR (the one whose next hashed owner name is - modified) should not be changed. - - o When adding an NSEC3 RR, the value of the Opt-Out flag is set to - the value of the Opt-Out flag of the NSEC3 RR that previously - covered the owner name of the NSEC3 RR. That is, the now previous - NSEC3 RR. - - If the zone in question is consistent with its use of the Opt-Out - flag (that is, all NSEC3 RRs in the zone have the same value for the - flag) then these rules will retain that consistency. If the zone is - not consistent in the use of the flag (i.e., a partially Opt-Out - zone), then these rules will not retain the same pattern of use of - the Opt-Out flag. - - - -Laurie, et al. Expires July 5, 2007 [Page 22] - -Internet-Draft nsec3 January 2007 - - - For zones that partially use the Opt-Out flag, if there is a logical - pattern for that use, the pattern could be maintained by using a - local policy on the server. - - -8. Validator Considerations - -8.1. Responses with Unknown Hash Types - - A validator MUST ignore NSEC3 RRs with unknown hash types. The - practical result of this is that responses containing only such NSEC3 - RRs will generally be considered bogus. - -8.2. Verifying NSEC3 RRs - - A validator MUST ignore NSEC3 RRs with a Flag fields value other than - zero or one. - - A validator MAY treat a response as bogus if the response contains - NSEC3 RRs that contain different values for hash algorithm, - iterations, or salt from each other. - -8.3. Closest Encloser Proof - - In order to verify a closest encloser proof, the validator MUST find - the longest name, X, such that - - o X is an ancestor of QNAME that is matched by an NSEC3 RR present - in the response. This is a candidate for the closest encloser. - And: - - o The name one label longer than X (but still an ancestor of--or - equal to--QNAME) is covered by an NSEC3 RR present in the - response. - - One possible algorithm for verifying this proof is as follows: - - 1. Set SNAME=QNAME. Clear the flag. - - 2. Check whether SNAME exists: - - * If there is no NSEC3 RR in the response that matches SNAME - (i.e., an NSEC3 RR whose owner name is the same as the hash of - SNAME, prepended as a single label to the zone name), clear - the flag. - - * If there is an NSEC3 RR in the response that covers SNAME, set - the flag. - - - -Laurie, et al. Expires July 5, 2007 [Page 23] - -Internet-Draft nsec3 January 2007 - - - * If there is a matching NSEC3 RR in the response and the flag - was set, then the proof is complete, and SNAME is the closest - encloser. - - * If there is a matching NSEC3 RR in the response, but the flag - is not set, then the response is bogus. - - 3. Truncate SNAME by one label from the left, go to step 2. - - Once the closest encloser has been discovered, the validator MUST - check that the NSEC3 RR that has the closest encloser as the original - owner name is from the proper zone. The DNAME type bit must not be - set and the NS type bit may only be set if the SOA type bit is set. - If this is not the case, it would be an indication that an attacker - is using them to falsely deny the existence of RRs for which the - server is not authoritative. - - In the following descriptions, the phrase "a closest (provable) - encloser proof for X" means that the algorithm above (or an - equivalent algorithm) proves that X does not exist by proving that an - ancestor of X is its closest encloser. - -8.4. Validating Name Error Responses - - A validator MUST verify that there is a closest encloser proof for - QNAME present in the response and that there is an NSEC3 RR that - covers the wildcard at the closest encloser (i.e., the name formed by - prepending the asterisk label to the closest encloser.) - -8.5. Validating No Data Responses, QTYPE is not DS - - The validator MUST verify that an NSEC3 RR that matches QNAME is - present and that both the QTYPE and the CNAME type are not set in its - Type Bit Maps field. - - Note that this test also covers the case where the NSEC3 RR exists - because it corresponds to an empty non-terminal, in which case the - NSEC3 RR will have an empty Type Bit Maps field. - -8.6. Validating No Data Responses, QTYPE is DS - - If there is an NSEC3 RR that matches QNAME present in the response, - then that NSEC3 RR MUST NOT have the bits corresponding to DS and - CNAME set in its Type Bit Maps field. - - If there is no such NSEC3 RR, then the validator MUST verify that a - closest provable encloser proof for QNAME is present in the response, - and that the NSEC3 RR that covers the "next closer" name has the Opt- - - - -Laurie, et al. Expires July 5, 2007 [Page 24] - -Internet-Draft nsec3 January 2007 - - - Out bit set. - -8.7. Validating Wildcard No Data Responses - - The validator MUST verify a closest encloser proof for QNAME and MUST - find an NSEC3 RR present in the response that matches the wildcard - name generated by prepending the asterisk label to the closest - encloser. Furthermore, the bits corresponding to both QTYPE and - CNAME MUST NOT be set in the wildcard matching NSEC3 RR. - -8.8. Validating Wildcard Answer Responses - - The verified wildcard answer RRSet in the response provides the - validator with a (candidate) closest encloser for QNAME. This - closest encloser is the immediate ancestor to the generating - wildcard. - - Validators MUST verify that there is an NSEC3 RR that covers the - "next closer" name to QNAME present in the response. This proves - that QNAME itself did not exist and that the correct wildcard was - used to generate the response. - -8.9. Validating Referrals to Unsigned Subzones - - The delegation name in a referral is the owner name of the NS RRSet - present in the authority section of the referral response. - - If there is an NSEC3 RR present in the response that matches the - delegation name, then the validator MUST ensure that the NS bit is - set and that the DS bit is not set in the Type Bit Maps field of the - NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from - the correct (i.e., parent) zone. This is done by ensuring that the - SOA bit is not set in the Type Bit Maps field of this NSEC3 RR. - - Note that the presence of an NS bit implies the absence of a DNAME - bit, so there is no need to check for the DNAME bit in the Type Bit - Maps field of the NSEC3 RR. - - If there is no NSEC3 RR present that matches the delegation name, - then the validator MUST verify a closest provable encloser proof for - the delegation name. The validator MUST verify that the Opt-Out bit - is set in the NSEC3 RR that covers the "next closer" name to the - delegation name. - - -9. Resolver Considerations - - - - - -Laurie, et al. Expires July 5, 2007 [Page 25] - -Internet-Draft nsec3 January 2007 - - -9.1. NSEC3 Resource Record Caching - - Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs - when returning responses that contain them. In DNSSEC [RFC4035], in - many cases it is possible to find the correct NSEC RR to return in a - response by name (e.g., when returning a referral, the NSEC RR will - always have the same owner name as the delegation.) With this - specification, that will not be true, nor will a cache be able to - calculate the name(s) of the appropriate NSEC3 RR(s). - Implementations may need to use new methods for caching and - retrieving NSEC3 RRs. - -9.2. Use of the AD Bit - - The AD bit, as defined by [RFC4035], MUST NOT be set when returning a - response containing a closest (provable) encloser proof in which the - NSEC3 RR that covers the "next closer" name has the Opt-Out bit set. - - This rule is based on what this closest encloser proof actually - proves: names that would be covered by the Opt-Out NSEC3 RR may or - may not exist as insecure delegations. As such, not all the data in - responses containing such closest encloser proofs will have been - cryptographically verified, so the AD bit cannot be set. - - -10. Special Considerations - -10.1. Domain Name Length Restrictions - - Zones signed using this specification have additional domain name - length restrictions imposed upon them. In particular, zones with - names that, when converted into hashed owner names, exceed the 255 - octet length limit imposed by [RFC1035] cannot use this - specification. - - The actual maximum length of a domain name in a particular zone - depends on both the length of the zone name (versus the whole domain - name) and the particular hash function used. - -10.2. DNAME at the Zone Apex - - The DNAME specification [RFC2672] section 3 has a 'no-descendants' - limitation. If a DNAME RR is present at node N, there MUST be no - data at any descendant of N. - - If N is the apex of the zone, there will be NSEC3 and RRSIG types - present at descendants of N. This specification updates the DNAME - specification to allow NSEC3 and RRSIG types at descendants of the - - - -Laurie, et al. Expires July 5, 2007 [Page 26] - -Internet-Draft nsec3 January 2007 - - - apex regardless of the existence of DNAME at the apex. - -10.3. Iterations - - Setting the number of iterations used allows the zone owner to choose - the cost of computing a hash, and so the cost of generating a - dictionary. Note that this is distinct from the effect of salt, - which prevents the use of a single precomputed dictionary for all - time. - - Obviously the number of iterations also affects the zone owner's cost - of signing and serving the zone as well as the validator's cost of - verifying responses from the zone. We therefore impose an upper - limit on the number of iterations. We base this on the number of - iterations that approximates the cost of verifying an RRSet. - - The limits, therefore, are based on the size of the smallest zone - signing key, rounded up to the nearest table value (or rounded down - if the key is larger than the largest table value.) - - A zone owner MUST NOT use a value higher than shown in the table - below for iterations for the given key size. A resolver MAY treat a - response with a higher value as insecure, after the validator has - verified that the signature over the NSEC3 RR is correct. - - +--------------+------------+ - | RSA Key Size | Iterations | - +--------------+------------+ - | 1024 | 150 | - | 2048 | 500 | - | 4096 | 2,500 | - +--------------+------------+ - - +--------------+------------+ - | DSA Key Size | Iterations | - +--------------+------------+ - | 1024 | 1,500 | - | 2048 | 5,000 | - +--------------+------------+ - - This table is based on 150,000 SHA-1 calculations per second, 1000 - RSA verifications per second for 1024 bit keys, 300 verifications per - second for 2048 bit keys, 60 verifications per second for 4096 bit - keys, 100 DSA verifications per second for 1024 bit keys and 30 - verifications per second for 2048 bit keys. - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 27] - -Internet-Draft nsec3 January 2007 - - -10.4. Transitioning a Signed Zone from NSEC to NSEC3 - - When transitioning an already signed and trusted zone to this - specification, care must be taken to prevent client validation - failures during the process. - - The basic procedure is as follows: - - 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases - described in Section 2. The actual method for safely and - securely changing the DNSKEY RRSet of the zone is outside the - scope of this specification. However, the end result MUST be - that all DS RRs in the parent use the specified algorithm - aliases. - - After this transition is complete, all NSEC3-unaware clients will - treat the zone as insecure. At this point, the authoritative - server still returns negative and wildcard responses that contain - NSEC RRs. - - 2. Add signed NSEC3 RRs to the zone, either incrementally or all at - once. If adding incrementally, then the last RRSet added MUST be - the NSEC3PARAM RRSet. - - 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to - serving negative and wildcard responses with NSEC3 RRs according - to this specification. - - 4. Remove the NSEC RRs either incrementally or all at once. - -10.5. Transitioning a Signed Zone From NSEC3 to NSEC - - To safely transition back to a DNSSEC [RFC4035] signed zone, simply - reverse the procedure above: - - 1. Add NSEC RRs incrementally or all at once. - - 2. Remove the NSEC3PARAM RRSet. This will signal the server to use - the NSEC RRs for negative and wildcard responses. - - 3. Remove the NSEC3 RRs either incrementally or all at once. - - 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. - After this transition is complete, all NSEC3-unaware clients will - treat the zone as secure. - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 28] - -Internet-Draft nsec3 January 2007 - - -11. IANA Considerations - - This document updates the IANA registry "DOMAIN NAME SYSTEM - PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub- - registry "TYPES", by defining two new types. Section 3 defines the - NSEC3 RR type NN, (value 50 suggested). Section 4 defines the - NSEC3PARAM RR type MM (value 51 suggested). - - This document updates the IANA registry "DNS SECURITY ALGORITHM - NUMBERS - per [RFC4035]" - http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2 - defines the aliases DSA-NSEC3 (XX) and RSASHA1-NSEC3 (YY) for - respectively existing registrations DSA and RSASHA1. - - [### IMPORTANT RFC EDITOR INSTRUCTION: - - After the IANA allocation has been done the examples in the Appendix - will need to be updated. The signature generation algorithm includes - the requested RR types as input. - - The RFC editor should not edit the Appendices before the IANA - typecode has been assigned and the examples have been regenerated by - the editor.] - - Finally, this document creates a new IANA registry for NSEC3 hash - algorithms. This registry should be named "DNSSEC NSEC3 Hash - Algorithms". The initial contents of this registry are: - - 0 is Reserved - - 1 is SHA-1. - - 2-255 Available for assignment - - Assignment of additional NSEC3 hash algorithms in this registry - requires IETF Standards Action [RFC2434]. - - -12. Security Considerations - -12.1. Hashing Considerations - -12.1.1. Dictionary Attacks - - The NSEC3 RRs are still susceptible to dictionary attacks (i.e. the - attacker retrieves all the NSEC3 RRs, then calculates the hashes of - all likely domain names, comparing against the hashes found in the - NSEC3 RRs, and thus enumerating the zone). These are substantially - - - -Laurie, et al. Expires July 5, 2007 [Page 29] - -Internet-Draft nsec3 January 2007 - - - more expensive than enumerating the original NSEC RRs would have - been, and in any case, such an attack could also be used directly - against the name server itself by performing queries for all likely - names, though this would obviously be more detectable. The expense - of this off-line attack can be chosen by setting the number of - iterations in the NSEC3 RR. - - Zones are also susceptible to a pre-calculated dictionary attack -- - that is, a list of hashes for all likely names is computed once, then - NSEC3 RR is scanned periodically and compared against the precomputed - hashes. This attack is prevented by changing the salt on a regular - basis. - -12.1.2. Collisions - - Hash collisions between QNAME and the owner name of an NSEC3 RR may - occur. When they do, it will be impossible to prove the non- - existence of the colliding QNAME. However, with SHA-1, this is - highly unlikely (on the order of 1 in 2^160). Note that DNSSEC - already relies on the presumption that a cryptographic hash function - is second pre-image resistant, since these hash functions are used - for generating and validating signatures and DS RRs. - -12.1.3. Using New or Unknown Hash Algorithms - - Since validators are instructed to ignore NSEC3 RRs with unknown hash - algorithms, simply using a new or unknown hash algorithm directly - will lead to validation failures with clients that understand NSEC3 - but do not understand the hash algorithm. - - To prevent this, care must be taken to protect such clients. It is - suggested that a similar technique to the one being used in this - specification to protect older clients be employed (see Section 2.) - -12.1.4. Using High Iteration Values - - Since validators should treat responses containing NSEC3 RRs with - high iteration values as insecure, presence of just one signed NSEC3 - RR with a high iteration value in a zone provides attackers with a - possible downgrade attack. - - The attack is simply to remove any existing NSEC3 RRs from a - response, and replace or add a single (or multiple) NSEC3 RR that - uses a high iterations value to the response. Validators will then - be forced to treat the response as insecure. This attack would be - effective only when all of following conditions are met: - - - - - -Laurie, et al. Expires July 5, 2007 [Page 30] - -Internet-Draft nsec3 January 2007 - - - o There is at least one signed NSEC3 RR that uses a high iterations - value present in the zone. - - o The attacker has access to one or more of these NSEC3 RRs. This - is trivially true when the NSEC3 RRs with high iterations values - are being returned in typical responses, but may also be true if - the attacker can access the zone via AXFR or IXFR queries, or any - other methodology. - - Using a high number of iterations also introduces an additional - denial-of-service opportunity against servers, since servers must - calculate several hashes per negative or wildcard response. - -12.2. Opt-Out Considerations - - The Opt-Out Flag (O) allows for unsigned names, in the form of - delegations to unsigned zones, to exist within an otherwise signed - zone. All unsigned names are, by definition, insecure, and their - validity or existence cannot be cryptographically proven. - - In general: - - o Resource records with unsigned names (whether existing or not) - suffer from the same vulnerabilities as RRs in an unsigned zone. - These vulnerabilities are described in more detail in [RFC3833] - (note in particular sections 2.3, "Name Chaining" and 2.6, - "Authenticated Denial of Domain Names"). - - o Resource records with signed names have the same security whether - or not Opt-Out is used. - - Note that with or without Opt-Out, an insecure delegation may be - undetectably altered by an attacker. Because of this, the primary - difference in security when using Opt-Out is the loss of the ability - to prove the existence or nonexistence of an insecure delegation - within the span of an Opt-Out NSEC3 RR. - - In particular, this means that a malicious entity may be able to - insert or delete RRs with unsigned names. These RRs are normally NS - RRs, but this also includes signed wildcard expansions (while the - wildcard RR itself is signed, its expanded name is an unsigned name). - - Note that being able to add a delegation is functionally equivalent - to being able to add any RR type: an attacker merely has to forge a - delegation to name server under his/her control and place whatever - RRs needed at the subzone apex. - - While in particular cases, this issue may not present a significant - - - -Laurie, et al. Expires July 5, 2007 [Page 31] - -Internet-Draft nsec3 January 2007 - - - security problem, in general it should not be lightly dismissed. - Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. - In particular, zone signing tools SHOULD NOT default to using Opt- - Out, and MAY choose to not support Opt-Out at all. - -12.3. Other Considerations - - Walking the NSEC3 RRs will reveal the total number of RRs in the zone - (plus empty non-terminals), and also what types there are. This - could be mitigated by adding dummy entries, but certainly an upper - limit can always be found. - - -13. References - -13.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, - "Domain Name System (DNS) IANA Considerations", BCP 42, - RFC 2929, September 2000. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - - - -Laurie, et al. Expires July 5, 2007 [Page 32] - -Internet-Draft nsec3 January 2007 - - - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 4648, October 2006. - -13.2. Informative References - - [I-D.ietf-dnsext-dnssec-opt-in] - Blacka, D., "DNSSEC Opt-In", - draft-ietf-dnsext-dnssec-opt-in-09 (work in progress), - June 2006. - - [I-D.jas-dnsext-no] - Josefsson, S., "Authenticating denial of existence in DNS - with minimum disclosure", draft-jas-dnsext-no-00 (work in - progress), July 2000. - - [I-D.laurie-dnsext-nsec2v2] - Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", - draft-laurie-dnsext-nsec2v2-00 (work in progress), - December 2004. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain - Name System (DNS)", RFC 3833, August 2004. - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - - -Appendix A. Example Zone - - This is a zone showing its NSEC3 RRs. They can also be used as test - vectors for the hash algorithm. - - The overall TTL and class are specified in the SOA RR, and are - subsequently omitted for clarity. - - - -Laurie, et al. Expires July 5, 2007 [Page 33] - -Internet-Draft nsec3 January 2007 - - - [### RFC-editor: the examples below needs to be regenerated - once IANA has completed its allocations, the document - editors will supply the modified text ] - - example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) - RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - NS ns1.example. - NS ns2.example. - RRSIG NS 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM - gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 - JpiZcff2Cj2B0w== ) - MX 1 xx.example. - RRSIG MX 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - jsGuTpXTTrZHzUKnViUpJ8YyGNpDd6n/sy2g - HnSC0nj2jPxTC5VENLo3GxSpCSA5DlAz57p+ - RllUJk3DWktkjw== ) - DNSKEY 256 3 133 ( - AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU - 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL - ExXT48OGGdbfIme5 ) - DNSKEY 257 3 133 ( - AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX - cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 - zsYKWJ7BvR2894hX ) - RRSIG DNSKEY 133 1 3600 20150420235959 ( - 20051021000000 22088 example. - Xpo9ptByXb8M1JR1i0KuRmKGc/YeOLcc6Ptn - RJOx6ADLSL2mU6AYX5tAJRMTKTXk6waLIaxu - liqUBOkCjLUZMw== ) - NSEC3PARAM 1 0 12 aabbccdd - RRSIG NSEC3PARAM 133 1 3600 20150420235959 ( - 20051021000000 62827 example. - LIDOPjIUc2DtDpXUlOaLnJkHKbacDvXZlhRm - g4eFGnaEd794HnjRjeT9w5QwtLDpLyyMRbGt - 4L0XlqhGJCcAsA== ) - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - - - -Laurie, et al. Expires July 5, 2007 [Page 34] - -Internet-Draft nsec3 January 2007 - - - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - GtJTFlvT5eYaK3rNUPQjpCKoIefvWZxQrDxU - jYsmoIWdLOVOuD5ZSDDQA3anDctOHdA/XbXn - o2uyWso1OzVlgg== ) - NSEC3 1 1 12 aabbccdd ( - 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - MOyKYIjbWDwnme6WV5R9kY9WWCjTPxcjYo+c - vWgJRnmXYZtz0bYqqELIalZtHsT2W0BOtCxS - Y2gIduy/7FVk0g== ) - 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( - 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - oBio/cYM5olvRWV3zW+IToAT3mU0gqbU+gZu - 7VysaXXufogv2B0ciYH29jdrRjvcCadsy/5E - Yj/THQIqFXEdOw== ) - 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( - b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM - UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 - Si8JqvOk+TRYqA== ) - a.example. NS ns1.a.example. - NS ns2.a.example. - DS 58470 5 1 ( - 3079F1593EBAD6DC121E202A8B766A6A4837206C ) - RRSIG DS 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - qxw4j5LNe70UDu121YqAaqQjyjYbdKNd/4bE - nH0kjQswuiGs9EuArCBhcWocWQDBku+A4HMH - JdLqJr5p4JctLg== ) - ns1.a.example. A 192.0.2.5 - ns2.a.example. A 192.0.2.6 - ai.example. A 192.0.2.9 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag - lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 - BXfXAqURwLqznA== ) - HINFO "KLH-10" "ITS" - - - -Laurie, et al. Expires July 5, 2007 [Page 35] - -Internet-Draft nsec3 January 2007 - - - RRSIG HINFO 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - BuDv+No06VEcIsEnvBdjdKm6kxQGrhOgKEKb - Gsb8DJRjY7Lia+YG2//s6OlOIfxPmLlLiYpA - i3q2sEjTJhocGQ== ) - AAAA 2001:db8:0:0:0:0:f00:baa9 - RRSIG AAAA 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M - hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x - 2ruyuN0zC+PABA== ) - b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( - gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - E1RiKYSYiN2U5t1h29o63vWwg++iOyJxNhtp - K0FRNe1uc/ZMElEuSOl1mj7n7hoZExR4j7J4 - xDdGSZkZZ7Np+w== ) - c.example. NS ns1.c.example. - NS ns2.c.example. - ns1.c.example. A 192.0.2.7 - ns2.c.example. A 192.0.2.8 - gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( - ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA - RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - PC6xuuhgRizxo+NWTAL4BqOyRwGdjJNjdu7G - +s8PPW9M1/FObcnaxvrFqnKVIzIOIkD66U/K - 09DKQD9ILCfOlw== ) - ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( - k8udemvp1j2f7eg6jebps17vp3n8i58h ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - JbIr0ml7CyVwid1WyNbXlxmZ4s0ZPZOjSbQI - wZEky0ImECHZLpa9/dASklriA6Yg8lgUzsj4 - bJwVGJ6LFzD1fA== ) - k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( - kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - chrf07zCt7K33AE6ZeF4Ti7CtaGePugS+I8t - bEzAbluRk3BzLtCKxqDUFVl1FVgq8KrQPLgU - h7mwmVDRXopnDw== ) - kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( - q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - - - -Laurie, et al. Expires July 5, 2007 [Page 36] - -Internet-Draft nsec3 January 2007 - - - BHESCxzi1TT5+G1b5add7PkBqh+8UhIM2m4w - mrOam5jM443iKviA2oGTYtdawPB0xTIoHZe7 - SbrvmdDe+bjCNg== ) - ns1.example. A 192.0.2.1 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - ratEKfeWD/pJJHO/XqEINvOp3so7pn9Pphxn - fRiCOVsa527M/ucRcQqGYCF0CN4jAXhW+6BS - ZzT0om+VdioRmg== ) - ns2.example. A 192.0.2.2 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - mW/DJMbQyD5y5C+a70vWyIWZyQ+Xg1zzkWHX - w3jfqmePgpdJnMrpGOcRIpy5irCFWiCwTp2o - cPT+k0ccpxtkLQ== ) - q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( - r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 - tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu - W7Zo0HsSFJJLIw== ) - r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( - t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - OFXtK7DkTcIHFNeChJbdCgz5lX8ZOXVE4WeU - RGHgiz9VfmLiN18+S7ucSt/UXNhX2ZpYWchJ - FEmSZ39hZpTN0w== ) - t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA - RRSIG ) - RRSIG NSEC3 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - U7hZiI+Vxmcn9JLSxyOs0p4nf6+0ckmzLKX2 - hCte/8EVLibUfvzyN8sP1k4nIYmMfciwV+dB - 1HnaArgp+4wgOw== ) - *.w.example. MX 1 ai.example. - RRSIG MX 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR - c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq - a7Xfz/f9xzvSTw== ) - x.w.example. MX 1 xx.example. - RRSIG MX 133 3 3600 20150420235959 20051021000000 ( - 62827 example. - BLSDMos8kYR7+2U7iwwdqdhU82hzq0s57xtw - F08tWU/d19jrNO6LdWfBL/FJ8zL8ZpEjhh6b - - - -Laurie, et al. Expires July 5, 2007 [Page 37] - -Internet-Draft nsec3 January 2007 - - - 8cj0f5yQOUyShw== ) - x.y.w.example. MX 1 xx.example. - RRSIG MX 133 4 3600 20150420235959 20051021000000 ( - 62827 example. - GPzELyUCxrnyep8uMcqthUXjTqYBmgeaveb9 - 2vQgzUyPLLamNN/YqMHr6tGQNxeMAhclxUSQ - eoCggUBVhFfB1Q== ) - xx.example. A 192.0.2.10 - RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - Sz+fPqY8II1VDq+dY48Q40dq1aoBR2RAuhKg - QNKXEYcULtJo/hxxfEAkJSNBKU5QnHpnnT9L - jqaSdob7ZhdxHg== ) - HINFO "KLH-10" "TOPS-20" - RRSIG HINFO 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - YJFwmD0By0NpGEvO1nE1ZTH10XrmpKnVuAEI - cAxLLHyPs3qyGQdDEG7sQX5+PfiOGZrNmZef - 8NgQhW8kGEgN1Q== ) - AAAA 2001:db8:0:0:0:0:f00:baaa - RRSIG AAAA 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - VAJBlXoTOScrIM6yPlDsd9o05v39qIzFnemR - 2vgw1s4l8maJVWi9IHEg8oiypJvGwSCP1nFs - EOlXyNFQJ0fWGA== ) - - -Appendix B. Example Responses - - [### RFC-editor: the example below needs to be regenerated once IANA - has completed its allocations, the document editors will supply the - modified text ] - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1. Name Error - - An authoritative name error. The NSEC3 RRs prove that the name does - not exist and that there is no wildcard RR that should have been - expanded. - -;; Header: QR AA DO RCODE=3 -;; -;; Question -a.c.x.w.example. IN A - -;; Answer - - - -Laurie, et al. Expires July 5, 2007 [Page 38] - -Internet-Draft nsec3 January 2007 - - -;; (empty) - -;; Authority - -example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) -example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - -;; NSEC3 RR that covers the "next closer" name (c.x.w.example) -;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh - -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - - -;; NSEC3 RR that matches the closest encloser (x.w.example) -;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 - -b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( - gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) -b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - E1RiKYSYiN2U5t1h29o63vWwg++iOyJxNhtp - K0FRNe1uc/ZMElEuSOl1mj7n7hoZExR4j7J4 - xDdGSZkZZ7Np+w== ) - -;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example) -;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m - -35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( - b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) -35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM - UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 - Si8JqvOk+TRYqA== ) - -;; Additional - - - -Laurie, et al. Expires July 5, 2007 [Page 39] - -Internet-Draft nsec3 January 2007 - - -;; (empty) - - The query returned three NSEC3 RRs that prove that the requested data - does not exist and that no wildcard expansion applies. The negative - response is authenticated by verifying the NSEC3 RRs. The - corresponding RRSIGs indicate that the NSEC3 RRs are signed by an - "example" DNSKEY of algorithm 133 and with key tag 62827. The - resolver needs the corresponding DNSKEY RR in order to authenticate - this answer. - - One of the owner names of the NSEC3 RRs matches the closest encloser. - One of the NSEC3 RRs prove that there exists no longer name. One of - the NSEC3 RRs prove that there exists no wildcard RRSets that should - have been expanded. The closest encloser can be found by applying - the algorithm in section Section 8.3. - - In the above example, the name 'x.w.example' hashes to - 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might - be the closest encloser. To prove that 'c.x.w.example' and - '*.x.w.example' do not exist, these names are hashed to, - respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and - '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs - prove that these hashed owner names do not exist. - -B.2. No Data Error - - A "no data" response. The NSEC3 RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 40] - -Internet-Draft nsec3 January 2007 - - -;; Header: QR AA DO RCODE=0 -;; -;; Question -ns1.example. IN MX - -;; Answer -;; (empty) - -;; Authority -example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) -example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - -;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set. - -2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( - 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) -2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - MOyKYIjbWDwnme6WV5R9kY9WWCjTPxcjYo+c - vWgJRnmXYZtz0bYqqELIalZtHsT2W0BOtCxS - Y2gIduy/7FVk0g== ) -;; Additional -;; (empty) - - The query returned an NSEC3 RR that proves that the requested name - exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"), - but the requested RR type does not exist (type MX is absent in the - type code list of the NSEC3 RR), and was not a CNAME (type CNAME is - also absent in the type code list of the NSEC3 RR.) - -B.2.1. No Data Error, Empty Non-Terminal - - A "no data" response because of an empty non-terminal. The NSEC3 RR - proves that the name exists and that the requested RR type does not. - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 41] - -Internet-Draft nsec3 January 2007 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - y.w.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) - example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - - ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set. - - ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( - k8udemvp1j2f7eg6jebps17vp3n8i58h ) - ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - JbIr0ml7CyVwid1WyNbXlxmZ4s0ZPZOjSbQI - wZEky0ImECHZLpa9/dASklriA6Yg8lgUzsj4 - bJwVGJ6LFzD1fA== ) - - ;; Additional - ;; (empty) - - - The query returned an NSEC3 RR that proves that the requested name - exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"), - but the requested RR type does not exist (Type A is absent in the - Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty - non-terminal proof using NSECs, this is identical to a No Data Error. - This example is solely mentioned to be complete. - -B.3. Referral to an Opt-Out Unsigned Zone - - The NSEC3 RRs prove that nothing for this delegation was signed. - There is no proof that the unsigned delegation exists. - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 42] - -Internet-Draft nsec3 January 2007 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.c.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - c.example. NS ns1.c.example. - NS ns2.c.example. - - ;; NSEC3 RR that covers the "next closer" name (c.example) - ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck - - 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( - b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) - 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM - UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 - Si8JqvOk+TRYqA== ) - - ;; NSEC3 RR that matches the closest encloser (example) - ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom - - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) - 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - - ;; Additional - ns1.c.example. A 192.0.2.7 - ns2.c.example. A 192.0.2.8 - - - The query returned a referral to the unsigned "c.example." zone. The - response contains the closest provable encloser of "c.example" to be - "example", since the hash of "c.example" - ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR - and its Opt-Out bit is set. - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 43] - -Internet-Draft nsec3 January 2007 - - -B.4. Wildcard Expansion - - A query that was answered with a response containing a wildcard - expansion. The label count in the RRSIG RRSet in the answer section - indicates that a wildcard RRSet was expanded to produce this - response, and the NSEC3 RR proves that no "next closer" name exists - in the zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 44] - -Internet-Draft nsec3 January 2007 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. MX 1 ai.example. - a.z.w.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR - c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq - a7Xfz/f9xzvSTw== ) - - ;; Authority - example. NS ns1.example. - example. NS ns2.example. - example. RRSIG NS 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM - gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 - JpiZcff2Cj2B0w== ) - - ;; NSEC3 RR that covers the "next closer" name (z.w.example) - ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 - - q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( - r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) - q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 - tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu - W7Zo0HsSFJJLIw== ) - - ;; Additional - ai.example. A 192.0.2.9 - ai.example. RRSIG A 133 2 3600 20150420235959 20051021000000 ( - 62827 example. - qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag - lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 - BXfXAqURwLqznA== ) - ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9 - ai.example. RRSIG AAAA 133 2 3600 20150420235959 ( - 20051021000000 62827 example. - m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M - hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x - 2ruyuN0zC+PABA== ) - - - - - -Laurie, et al. Expires July 5, 2007 [Page 45] - -Internet-Draft nsec3 January 2007 - - - The query returned an answer that was produced as a result of - wildcard expansion. The answer section contains a wildcard RRSet - expanded as it would be in a traditional DNS response. The RRSIG - Labels field value of 2 indicates that the answer is the result of - wildcard expansion, as the "a.z.w.example" name contains 4 labels. - This also shows that "w.example" exists, so there is no need for an - NSEC3 RR that matches the closest encloser. - - The NSEC3 RR proves that no closer match could have been used to - answer this query. - -B.5. Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC3 RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) - example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - - ;; NSEC3 RR that matches the closest encloser (w.example) - ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h - - k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( - kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) - k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - chrf07zCt7K33AE6ZeF4Ti7CtaGePugS+I8t - bEzAbluRk3BzLtCKxqDUFVl1FVgq8KrQPLgU - h7mwmVDRXopnDw== ) - - ;; NSEC3 RR that covers the "next closer" name (z.w.example) - ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 - - - - -Laurie, et al. Expires July 5, 2007 [Page 46] - -Internet-Draft nsec3 January 2007 - - - q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( - r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) - q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 - tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu - W7Zo0HsSFJJLIw== ) - - ;; NSEC3 RR that matches a wildcard at the closest encloser. - ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en - - r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( - t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) - r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - OFXtK7DkTcIHFNeChJbdCgz5lX8ZOXVE4WeU - RGHgiz9VfmLiN18+S7ucSt/UXNhX2ZpYWchJ - FEmSZ39hZpTN0w== ) - - ;; Additional - ;; (empty) - - The query returned the NSEC3 RRs that prove that the requested data - does not exist and no wildcard RR applies. - -B.6. DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query that was mistakenly sent to - a name server for the child zone. - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 47] - -Internet-Draft nsec3 January 2007 - - -;; Header: QR AA DO RCODE=0 -;; -;; Question -example. IN DS - -;; Answer -;; (empty) - -;; Authority -example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( - 3600000 3600 ) -example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( - 62827 example. - hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ - ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ - rynLZNqsbLm40Q== ) - -;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set. - -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( - 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS - SOA NSEC3PARAM RRSIG ) -0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( - 20150420235959 20051021000000 62827 example. - Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 - DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu - +tM22fPvu7lfXQ== ) - -;; Additional -;; (empty) - - The query returned an NSEC3 RR showing that the requested was - answered by the server authoritative for the zone "example". The - NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3 - RR is from the apex of the child, not from the zone cut of the - parent. Queries for the "example" DS RRSet should be sent to the - parent servers (which are in this case the root servers). - - -Appendix C. Special Considerations - - The following paragraphs clarify specific behavior and explain - special considerations for implementations. - -C.1. Salting - - Augmenting original owner names with salt before hashing increases - the cost of a dictionary of pre-generated hash-values. For every bit - - - -Laurie, et al. Expires July 5, 2007 [Page 48] - -Internet-Draft nsec3 January 2007 - - - of salt, the cost of a precomputed dictionary doubles (because there - must be an entry for each word combined with each possible salt - value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of - salt, multiplying the cost by 2^2040. This means that an attacker - must, in practice, recompute the dictionary each time the salt is - changed. - - There MUST be at least one complete set of NSEC3 RRs for the zone - using the same salt value. - - The salt SHOULD be changed periodically to prevent pre-computation - using a single salt. It is RECOMMENDED that the salt be changed for - every re-signing. - - Note that this could cause a resolver to see RRs with different salt - values for the same zone. This is harmless, since each RR stands - alone (that is, it denies the set of owner names whose hashes, using - the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 - RR) - it is only the server that needs a complete set of NSEC3 RRs - with the same salt in order to be able to answer every possible - query. - - There is no prohibition with having NSEC3 RRs with different salts - within the same zone. However, in order for authoritative servers to - be able to consistently find covering NSEC3 RRs, the authoritative - server MUST choose a single set of parameters (algorithm, salt, and - iterations) to use when selecting NSEC3 RRs. - -C.2. Hash Collision - - Hash collisions occur when different messages have the same hash - value. The expected number of domain names needed to give a 1 in 2 - chance of a single collision is about 2^(n/2) for a hash of length n - bits (i.e. 2^80 for SHA-1). Though this probability is extremely - low, the following paragraphs deal with avoiding collisions and - assessing possible damage in the event of an attack using hash - collisions. - -C.2.1. Avoiding Hash Collisions During Generation - - During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occurring, an alternative salt - MUST be chosen and all hash values MUST be regenerated. - -C.2.2. Second Preimage Requirement Analysis - - A cryptographic hash function has a second-preimage resistance - property. The second-preimage resistance property means that it is - - - -Laurie, et al. Expires July 5, 2007 [Page 49] - -Internet-Draft nsec3 January 2007 - - - computationally infeasible to find another message with the same hash - value as a given message, i.e. given preimage X, to find a second - preimage X' != X such that hash(X) = hash(X'). The work factor for - finding a second preimage is of the order of 2^160 for SHA-1. To - mount an attack using an existing NSEC3 RR, an adversary needs to - find a second preimage. - - Assuming an adversary is capable of mounting such an extreme attack, - the actual damage is that a response message can be generated which - claims that a certain QNAME (i.e. the second pre-image) does exist, - while in reality QNAME does not exist (a false positive), which will - either cause a security aware resolver to re-query for the non- - existent name, or to fail the initial query. Note that the adversary - can't mount this attack on an existing name but only on a name that - the adversary can't choose and does not yet exist. - -C.2.3. Possible Hash Value Truncation Method - - The previous sections outlined the low probability and low impact of - a second-preimage attack. When impact and probability are low, while - space in a DNS message is costly, truncation is tempting. Truncation - might be considered to allow for shorter owner names and RDATA for - hashed labels. In general, if a cryptographic hash is truncated to n - bits, then the expected number of domains required to give a 1 in 2 - probability of a single collision is approximately 2^(n/2) and the - work factor to produce a second preimage is 2^n. - - An extreme hash value truncation would be truncating to the shortest - possible unique label value. This would be unwise, since the work - factor to produce second preimages would then approximate the size of - the zone (sketch of proof: if the zone has k entries, then the length - of the names when truncated down to uniqueness should be proportional - to log_2(k). Since the work factor to produce a second pre-image is - 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where - C is some constant), i.e. C'k - a work factor of k). - - Though the mentioned truncation can be maximized to a certain - extreme, the probability of collision increases exponentially for - every truncated bit. Given the low impact of hash value collisions - and limited space in DNS messages, the balance between truncation - profit and collision damage may be determined by local policy. Of - course, the size of the corresponding RRSIG RR is not reduced, so - truncation is of limited benefit. - - Truncation could be signaled simply by reducing the length of the - first label in the owner name. Note that there would have to be a - corresponding reduction in the length of the Next Hashed Owner Name - field. - - - -Laurie, et al. Expires July 5, 2007 [Page 50] - -Internet-Draft nsec3 January 2007 - - -Authors' Addresses - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - Phone: +44 20 8735 0686 - Email: ben@algroup.co.uk - - - Geoffrey Sisson - Nominet - Sandford Gate - Sandy Lane West - Oxford OX4 6LB - UNITED KINGDOM - - Phone: +44 1865 332211 - Email: geoff@nominet.org.uk - - - Roy Arends - Nominet - Sandford Gate - Sandy Lane West - Oxford OX4 6LB - UNITED KINGDOM - - Phone: +44 1865 332211 - Email: roy@nominet.org.uk - - - David Blacka - VeriSign, Inc. - 21355 Ridgetop Circle - Dulles, VA 20166 - US - - Phone: +1 703 948 3200 - Email: davidb@verisign.com - - - - - - - - - -Laurie, et al. Expires July 5, 2007 [Page 51] - -Internet-Draft nsec3 January 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Laurie, et al. Expires July 5, 2007 [Page 52] - diff --git a/doc/draft/draft-ietf-dnsext-nsec3-12.txt b/doc/draft/draft-ietf-dnsext-nsec3-12.txt new file mode 100644 index 00000000000..16e95a0b85a --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec3-12.txt @@ -0,0 +1,2968 @@ + + + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Intended status: Standards Track R. Arends +Expires: January 2, 2008 Nominet + D. Blacka + VeriSign, Inc. + July 2007 + + + DNSSEC Hashed Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-12 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 2, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + The Domain Name System Security Extensions (DNSSEC) introduced the + NSEC resource record (RR) for authenticated denial of existence. + This document introduces an alternative resource record, NSEC3, which + similarly provides authenticated denial of existence. However, it + also provides measures against zone enumeration and permits gradual + + + +Laurie, et al. Expires January 2, 2008 [Page 1] + +Internet-Draft nsec3 July 2007 + + + expansion of delegation-centric zones. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 6 + 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 7 + 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8 + 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9 + 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9 + 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 9 + 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 9 + 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10 + 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 11 + 4. The NSEC3PARAM Record . . . . . . . . . . . . . . . . . . . . 12 + 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12 + 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 12 + 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13 + 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13 + 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13 + 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 13 + 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 14 + 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 7. Authoritative Server Considerations . . . . . . . . . . . . . 15 + 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18 + 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 18 + 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19 + 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19 + 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 19 + 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 19 + 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20 + 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20 + 7.2.9. Server Response to a Run-time Collision . . . . . . . 20 + 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 20 + 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21 + + + +Laurie, et al. Expires January 2, 2008 [Page 2] + +Internet-Draft nsec3 July 2007 + + + 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21 + 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 22 + 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 22 + 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 22 + 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23 + 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24 + 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24 + 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24 + 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 24 + 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 24 + 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25 + 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25 + 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 25 + 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 25 + 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26 + 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26 + 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26 + 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 27 + 10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30 + 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30 + 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30 + 12.1.3. Transitioning to a New Hash Algorithm . . . . . . . . 30 + 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 31 + 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32 + 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 + Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 34 + Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 39 + B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 39 + B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 41 + B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 42 + B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 43 + B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45 + B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 47 + B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 48 + Appendix C. Special Considerations . . . . . . . . . . . . . . . 49 + C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 49 + C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 50 + C.2.1. Avoiding Hash Collisions During Generation . . . . . . 50 + C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 + Intellectual Property and Copyright Statements . . . . . . . . . . 53 + + + +Laurie, et al. Expires January 2, 2008 [Page 3] + +Internet-Draft nsec3 July 2007 + + +1. Introduction + +1.1. Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of existence, it introduces a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + The enumeration is enabled by the set of NSEC records that exists in + a side signed zone. An NSEC record lists two names that are ordered + canonically, in order to show that nothing exists between the two + names. The complete set of NSEC records lists all the names in a + zone. It is trivial to enumerate the content of a zone by querying + for names that do not exist. + + An enumerated zone can be used, for example, as a source of probable + e-mail addresses for spam, or as a key for multiple WHOIS queries to + reveal registrant data which many registries may have legal + obligations to protect. Many registries therefore prohibit copying + of their zone data; however, the use of NSEC RRs renders these + policies unenforceable. + + A second problem is that the cost to cryptographically secure + delegations to unsigned zones is high, relative to the perceived + security benefit, in two cases: large, delegation-centric zones, and + zones where insecure delegations will be updated rapidly. In these + cases, the costs of maintaining the NSEC RR chain may be extremely + high and use of the "Opt-Out" convention may be more appropriate (for + these unsecured zones). + + This document presents the NSEC3 Resource Record which can be used as + an alternative to NSEC to mitigate these issues. + + Earlier work to address these issues include [I-D.jas-dnsext-no], + [RFC4956] and [I-D.laurie-dnsext-nsec2v2]. + +1.2. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.3. Terminology + + The reader is assumed to be familiar with the basic DNS and DNSSEC + concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], + + + +Laurie, et al. Expires January 2, 2008 [Page 4] + +Internet-Draft nsec3 July 2007 + + + [RFC4035] and subsequent RFCs that update them: [RFC2136], [RFC2181] + and [RFC2308]. + + The following terminology is used throughout this document: + + Zone enumeration: the practice of discovering the full content of a + zone via successive queries. Zone enumeration was non-trivial + prior to the introduction of DNSSEC. + + Original owner name: the owner name corresponding to a hashed owner + name. + + Hashed owner name: the owner name created after applying the hash + function to an owner name. + + Hash order: the order in which hashed owner names are arranged + according to their numerical value, treating the leftmost (lowest + numbered) octet as the most significant octet. Note that this + order is the same as the canonical DNS name order specified in + [RFC4034] when the hashed owner names are in base32 encoded with + Extended Hex Alphabet [RFC4648]. + + Empty non-terminal: a domain name that owns no resource records, but + has one or more subdomains that do. + + Delegation: an NS RRSet with a name different from the current zone + apex (non-zone-apex), signifying a delegation to a child zone. + + Secure delegation: a name containing a delegation (NS RRSet), and a + signed DS RRSet, signifying a delegation to a signed child zone. + + Insecure delegation: a name containing a delegation (NS RRSet), but + lacking a DS RRSet, signifying a delegation to an unsigned child + zone. + + Opt-Out NSEC3 resource record: an NSEC3 resource record which has + the Opt-Out flag set to 1. + + Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR. + + Closest encloser: the longest existing ancestor of a name. See also + section 3.3.1 of [RFC4592]. + + Closest provable encloser: the longest ancestor of a name that can + be proven to exist. Note that this is only different from the + closest encloser in an Opt-Out zone. + + + + + +Laurie, et al. Expires January 2, 2008 [Page 5] + +Internet-Draft nsec3 July 2007 + + + Next closer name: the name one label longer than the closest + provable encloser of a name. + + Base32: the "Base 32 Encoding with Extended Hex Alphabet" as + specified in [RFC4648]. Note that trailing padding characters + ("=") are not used in the NSEC3 specification. + + To cover: An NSEC3 RR is said to "cover" a name if the hash of the + name or "next closer" name falls between the owner name and the + next hashed owner name of the NSEC3. In other words, if it proves + the nonexistence of the name, either directly or by proving the + nonexistence of an ancestor of the name. + + To match: An NSEC3 RR is said to "match" a name if the owner name of + the NSEC3 RR is the same as the hashed owner name of that name. + + +2. Backwards Compatibility + + This specification describes a protocol change that is not generally + backwards compatible with [RFC4033], [RFC4034] and [RFC4035]. In + particular, security-aware resolvers that are unaware of this + specification (NSEC3-unaware resolvers) may fail to validate the + responses introduced by this document. + + In order to aid deployment, this specification uses a signaling + technique to prevent NSEC3-unaware resolvers from attempting to + validate responses from NSEC3-signed zones. + + This specification allocates two new DNSKEY algorithm identifiers for + this purpose. Algorithm XX, DSA-NSEC3-SHA1 [### RFC-editor update + required, temporarily, XX=131] is an alias for algorithm 3, DSA. + Algorithm YY, RSASHA1-NSEC3-SHA1 [### RFC-editor update required, + temporarily, YY=133] is an alias for algorithm 5, RSASHA1. These are + not new algorithms, they are additional identifiers for the existing + algorithms. + + Zones signed according to this specification MUST only use these + algorithm identifiers for their DNSKEY RRs. Because these new + identifiers will be unknown algorithms to existing, NSEC3-unaware + resolvers, those resolvers will then treat responses from the NSEC3 + signed zone as insecure, as detailed in [RFC4035], section 5.2. + + These algorithm identifiers are used with the NSEC3 hash algorithm + SHA1. Using other NSEC3 hash algorithms requires allocation of a new + alias (see Section 12.1.3). + + Security aware resolvers that are aware of this specification MUST + + + +Laurie, et al. Expires January 2, 2008 [Page 6] + +Internet-Draft nsec3 July 2007 + + + recognize the new algorithm identifiers and treat them as equivalent + to the algorithms that they alias. + + A methodology for transitioning from a DNSSEC signed zone to a zone + signed using NSEC3 is discussed in Section 10.4. + + +3. The NSEC3 Resource Record + + The NSEC3 Resource Record (RR) provides authenticated denial of + existence for DNS Resource Record Sets. + + The NSEC3 RR lists RR types present at the original owner name of the + NSEC3 RR. It includes the next hashed owner name in the hash order + of the zone. The complete set of NSEC3 RRs in a zone indicates which + RRSets exist for the original owner name of the RR and form a chain + of hashed owner names in the zone. This information is used to + provide authenticated denial of existence for DNS data. To provide + protection against zone enumeration, the owner names used in the + NSEC3 RR are cryptographic hashes of the original owner name + prepended as a single label to the name of the zone. The NSEC3 RR + indicates which hash function is used to construct the hash, which + salt is used, and how many iterations of the hash function are + performed over the original owner name. The hashing technique is + described fully in Section 5. + + Hashed owner names of unsigned delegations may be excluded from the + chain. An NSEC3 RR whose span covers the hash of an owner name or + "next closer" name of an unsigned delegation is referred to as an + Opt-Out NSEC3 RR and is indicated by the presence of a flag. + + The owner name for the NSEC3 RR is the base32 encoding of the hashed + owner name prepended as a single label to the name of the zone. + + The type value for the NSEC3 RR is NN. [### RFC-editor update + required, the examples assume NN=50] + + The NSEC3 RR RDATA format is class independent and is described + below. + + The class MUST be the same as the class of the original owner name. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 7] + +Internet-Draft nsec3 July 2007 + + +3.1. RDATA Fields + +3.1.1. Hash Algorithm + + The Hash Algorithm field identifies the cryptographic hash algorithm + used to construct the hash-value. + + The values for this field are defined in the NSEC3 hash algorithm + registry, described in Section 11. + +3.1.2. Flags + + The Flags field contains 8 one-bit flags that can be used to indicate + different processing. All undefined flags must be zero. The only + flag defined by this specification is the Opt-Out flag. + +3.1.2.1. Opt-Out Flag + + If the Opt-Out flag is set, the NSEC3 record covers zero or more + unsigned delegations. + + If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned + delegations. + + The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned + delegations. It is the least significant bit in the Flags field. + See Section 6 for details about the use of this flag. + +3.1.3. Iterations + + The Iterations field defines the number of additional times the hash + function has been performed. More iterations result in greater + resiliency of the hash value against dictionary attacks, but at a + higher computational cost for both the server and resolver. See + Section 5 for details of the use of this field, and Section 10.3 for + limitations on the value. + +3.1.4. Salt Length + + The Salt Length field defines the length of the Salt field in octets, + ranging in value from 0 to 255. + +3.1.5. Salt + + The Salt field is appended to the original owner name before hashing + in order to defend against pre-calculated dictionary attacks. See + Section 5 for details on how the salt is used. + + + + +Laurie, et al. Expires January 2, 2008 [Page 8] + +Internet-Draft nsec3 July 2007 + + +3.1.6. Hash Length + + The Hash Length field defines the length of the Next Hashed Owner + Name field, ranging in value from 1 to 255 octets. + +3.1.7. Next Hashed Owner Name + + The Next Hashed Owner Name field contains the next hashed owner name + in hash order. This value is in binary format. Given the ordered + set of all hashed owner names, the Next Hashed Owner Name field + contains the hash of an owner name that immediately follows the owner + name of the given NSEC3 RR. The value of the Next Hashed Owner Name + field in the last NSEC3 RR in the zone is the same as the hashed + owner name of the first NSEC3 RR in the zone in hash order. Note + that, unlike the owner name of the NSEC3 RR, the value of this field + does not contain the appended zone name. + +3.1.8. Type Bit Maps + + The Type Bit Maps field identifies the RRSet types which exist at the + original owner name of the NSEC3 RR. + +3.2. NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash Alg. | Flags | Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash Length | Next Hashed Owner Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Hash Algorithm is a single octet. + + Flags field is a single octet, the Opt-Out flag is the least + significant bit, as shown below: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | |O| + +-+-+-+-+-+-+-+-+ + + + + +Laurie, et al. Expires January 2, 2008 [Page 9] + +Internet-Draft nsec3 July 2007 + + + Iterations is represented as a 16-bit unsigned integer, with the most + significant bit first. + + Salt Length is represented as an unsigned octet. Salt Length + represents the length of the Salt field in octets. If the value is + zero, the following Salt field is omitted. + + Salt, if present, is encoded as a sequence of binary octets. The + length of this field is determined by the preceding Salt Length + field. + + Hash Length is represented as an unsigned octet. Hash Length + represents the length of the Next Hashed Owner Name field in octets. + + The next hashed owner name is not base32 encoded, unlike the owner + name of the NSEC3 RR. It is the unmodified binary hash value. It + does not include the name of the containing zone. The length of this + field is determined by the preceding Hash Length field. + +3.2.1. Type Bit Maps Encoding + + The encoding of the Type Bit Maps field is the same as that used by + the NSEC RR, described in [RFC4034]. It is explained and clarified + here for clarity. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the bitmap of the + window block, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC3 RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRSet of that type is present for the + original owner name of the NSEC3 RR. If a bit is set to 0, it + indicates that no RRSet of that type is present for the original + owner name of the NSEC3 RR. + + + +Laurie, et al. Expires January 2, 2008 [Page 10] + +Internet-Draft nsec3 July 2007 + + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in [RFC2929] + (section 3.1) or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in + zone data. If encountered, they must be ignored upon reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of the bitmap of + each block is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + original owner name of the NSEC3 RR. Trailing octets not specified + MUST be interpreted as zero octets. + +3.3. Presentation Format + + The presentation format of the RDATA portion is as follows: + + o The Hash Algorithm field is represented as an unsigned decimal + integer. The value has a maximum of 255. + + o The Flags field is represented as an unsigned decimal integer. + The value has a maximum of 255. + + o The Iterations field is represented as an unsigned decimal + integer. The value is between 0 and 65535, inclusive. + + o The Salt Length field is not represented. + + o The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the + sequence. The Salt field is represented as "-" (without the + quotes) when the Salt Length field has value 0. + + o The Hash Length field is not represented. + + o The Next Hashed Owner Name field is represented as an unpadded + sequence of case-insensitive base32 digits, without whitespace. + + o The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE + representation as described in [RFC3597] (section 5) MUST be used. + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 11] + +Internet-Draft nsec3 July 2007 + + +4. The NSEC3PARAM Record + + The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, + flags, iterations and salt) needed by authoritative servers to + calculate hashed owner names. The presence of an NSEC3PARAM RR at a + zone apex indicates that the specified parameters may be used by + authoritative servers to choose an appropriate set of NSEC3 RRs for + negative responses. The NSEC3PARAM RR is not used by validators or + resolvers. + + If an NSEC3PARAM RR is present at the apex of a zone with a Flags + field value of zero, then there MUST be an NSEC3 RR using the same + hash algorithm, iterations and salt parameters present at every + hashed owner name in the zone. That is, the zone MUST contain a + complete set of NSEC3 RRs with the same hash algorithm, iterations + and salt parameters. + + The owner name for the NSEC3PARAM RR is the name of the zone apex. + + The type value for the NSEC3PARAM RR is MM. [### RFC-editor update + required, the examples assume MM=51] + + The NSEC3PARAM RR RDATA format is class independent and is described + below. + + The class MUST be the same as the NSEC3 RRs to which this RR refers. + +4.1. RDATA Fields + + The RDATA for this RR mirrors the first four fields in the NSEC3 RR. + +4.1.1. Hash Algorithm + + The Hash Algorithm field identifies the cryptographic hash algorithm + used to construct the hash-value. + + The acceptable values are the same as the corresponding field in the + NSEC3 RR. + +4.1.2. Flag Fields + + The Opt-Out flag is not used and is set to zero. + + All other flags are reserved for future use, and must be zero. + + NSEC3PARAM RRs with a Flags field value other than zero MUST be + ignored. + + + + +Laurie, et al. Expires January 2, 2008 [Page 12] + +Internet-Draft nsec3 July 2007 + + +4.1.3. Iterations + + The Iterations field defines the number of additional times the hash + is performed. + + Its acceptable values are the same as the corresponding field in the + NSEC3 RR. + +4.1.4. Salt Length + + The Salt Length field defines the length of the salt in octets, + ranging in value from 0 to 255. + +4.1.5. Salt + + The Salt field is appended to the original owner name before hashing. + +4.2. NSEC3PARAM RDATA Wire Format + + The RDATA of the NSEC3PARAM RR is as shown below: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash Alg. | Flags | Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Hash Algorithm is a single octet. + + Flags field is a single octet. + + Iterations is represented as a 16-bit unsigned integer, with the most + significant bit first. + + Salt Length is represented as an unsigned octet. Salt Length + represents the length of the following Salt field in octets. If the + value is zero, the Salt field is omitted. + + Salt, if present, is encoded as a sequence of binary octets. The + length of this field is determined by the preceding Salt Length + field. + +4.3. Presentation Format + + The presentation format of the RDATA portion is as follows: + + + + +Laurie, et al. Expires January 2, 2008 [Page 13] + +Internet-Draft nsec3 July 2007 + + + o The Hash Algorithm field is represented as an unsigned decimal + integer. The value has a maximum of 255. + + o The Flags field is represented as an unsigned decimal integer. + The value has a maximum value of 255. + + o The Iterations field is represented as an unsigned decimal + integer. The value is between 0 and 65535, inclusive. + + o The Salt Length field is not represented. + + o The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the + sequence. This field is represented as "-" (without the quotes) + when the Salt Length field is zero. + + +5. Calculation of the Hash + + The hash calculation uses three of the NSEC3 RDATA fields: Hash + Algorithm, Salt, and Iterations. + + Define H(x) to be the hash of x using the Hash Algorithm selected by + the NSEC3 RR, k to be the number of Iterations, and || to indicate + concatenation. Then define: + + IH(salt, x, 0) = H(x || salt), and + + IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0 + + Then the calculated hash of an owner name is + + IH(salt, owner name, iterations), + + where the owner name is in the canonical form, defined as: + + The wire format of the owner name where: + + 1. The owner name is fully expanded (no DNS name compression) and + fully qualified; + + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + + 3. If the owner name is a wildcard name, the owner name is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + + + + +Laurie, et al. Expires January 2, 2008 [Page 14] + +Internet-Draft nsec3 July 2007 + + + This form is as defined in section 6.2 of [RFC4034]. + + The method to calculate the Hash is based on [RFC2898]. + + +6. Opt-Out + + In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS + RRSets at delegation points are not signed and may be accompanied by + a DS RRSet. With the Opt-Out bit clear, the security status of the + child zone is determined by the presence or absence of this DS RRSet, + cryptographically proven by the signed NSEC3 RR at the hashed owner + name of the delegation. Setting the Opt-Out flag modifies this by + allowing insecure delegations to exist within the signed zone without + a corresponding NSEC3 RR at the hashed owner name of the delegation. + + An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the + owner name or "next closer" name of the delegation is between the + owner name of the NSEC3 RR and the next hashed owner name. + + An Opt-Out NSEC3 RR does not assert the existence or non-existence of + the insecure delegations that it may cover. This allows for the + addition or removal of these delegations without recalculating or re- + signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do + assert the (non)existence of other, authoritative RRSets. + + An Opt-Out NSEC3 RR MAY have the same original owner name as an + insecure delegation. In this case, the delegation is proven insecure + by the lack of a DS bit in the type map and the signed NSEC3 RR does + assert the existence of the delegation. + + Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and + non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT + be any hashed owner names of insecure delegations (nor any other RRs) + between it and the name indicated by the next hashed owner name in + the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner + names or hashed "next closer" names of insecure delegations. + + The effects of the Opt-Out flag on signing, serving, and validating + responses are covered in following sections. + + +7. Authoritative Server Considerations + +7.1. Zone Signing + + Zones using NSEC3 must satisfy the following properties: + + + + +Laurie, et al. Expires January 2, 2008 [Page 15] + +Internet-Draft nsec3 July 2007 + + + o Each owner name within the zone that owns authoritative RRSets + MUST have a corresponding NSEC3 RR. Owner names that correspond + to unsigned delegations MAY have a corresponding NSEC3 RR. + However, if there is not a corresponding NSEC3 RR, there MUST be + an Opt-Out NSEC3 RR that covers the "next closer" name to the + delegation. Other non-authoritative RRs are not represented by + NSEC3 RRs. + + o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless + the empty non-terminal is only derived from an insecure delegation + covered by an Opt-Out NSEC3 RR. + + o The TTL value for any NSEC3 RR SHOULD be the same as the minimum + TTL value field in the zone SOA RR. + + o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST + indicate the presence of all types present at the original owner + name, except for the types solely contributed by an NSEC3 RR + itself. Note that this means that the NSEC3 type itself will + never be present in the Type Bit Maps. + + The following steps describe a method of proper construction of NSEC3 + RRs. This is not the only such possible method. + + 1. Select the hash algorithm and the values for salt and iterations. + + 2. For each unique original owner name in the zone add an NSEC3 RR. + + * If Opt-Out is being used, owner names of unsigned delegations + MAY be excluded. + + * The owner name of the NSEC3 RR is the hash of the original + owner name, prepended as a single label to the zone name. + + * The Next Hashed Owner Name field is left blank for the moment. + + * If Opt-Out is being used, set the Opt-Out bit to one. + + * For collision detection purposes, optionally keep track of the + original owner name with the NSEC3 RR. + + * Additionally, for collision detection purposes, optionally + create an additional NSEC3 RR corresponding to the original + owner name with the asterisk label prepended (i.e., as if a + wildcard existed as a child of this owner name) and keep track + of this original owner name. Mark this NSEC3 RR as temporary. + + + + + +Laurie, et al. Expires January 2, 2008 [Page 16] + +Internet-Draft nsec3 July 2007 + + + 3. For each RRSet at the original owner name, set the corresponding + bit in the Type Bit Maps field. + + 4. If the difference in number of labels between the apex and the + original owner name is greater than 1, additional NSEC3 RRs need + to be added for every empty non-terminal between the apex and the + original owner name. This process may generate NSEC3 RRs with + duplicate hashed owner names. Optionally, for collision + detection, track the original owner names of these NSEC3 RRs and + create temporary NSEC3 RRs for wildcard collisions in a similar + fashion to step 1. + + 5. Sort the set of NSEC3 RRs into hash order. + + 6. Combine NSEC3 RRs with identical hashed owner names by replacing + them with a single NSEC3 RR with the Type Bit Maps field + consisting of the union of the types represented by the set of + NSEC3 RRs. If the original owner name was tracked, then + collisions may be detected when combining, as all of the matching + NSEC3 RRs should have the same original owner name. Discard any + possible temporary NSEC3 RRs. + + 7. In each NSEC3 RR, insert the next hashed owner name by using the + value of the next NSEC3 RR in hash order. The next hashed owner + name of the last NSEC3 RR in the zone contains the value of the + hashed owner name of the first NSEC3 RR in the hash order. + + 8. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, + Iterations and Salt fields to the zone apex. + + If a hash collision is detected, then a new salt has to be chosen and + the signing process restarted. + +7.2. Zone Serving + + This specification modifies DNSSEC-enabled DNS responses generated by + authoritative servers. In particular, it replaces the use of NSEC + RRs in such responses with NSEC3 RRs. + + In the following response cases, the NSEC RRs dictated by DNSSEC + [RFC4035] are replaced with NSEC3 RRs that prove the same facts. + Responses that would not contain NSEC RRs are unchanged by this + specification. + + When returning responses containing multiple NSEC3 RRs, all of the + NSEC3 RRs MUST use the same hash algorithm, iteration, and salt + values. The Flags field value MUST be either zero or one. + + + + +Laurie, et al. Expires January 2, 2008 [Page 17] + +Internet-Draft nsec3 July 2007 + + +7.2.1. Closest Encloser Proof + + For many NSEC3 responses a proof of the closest encloser is required. + This is a proof that some ancestor of the QNAME is the closest + encloser of QNAME. + + This proof consists of (up to) two different NSEC3 RRs: + + o An NSEC3 RR that matches the closest (provable) encloser. + + o An NSEC3 RR that covers the "next closer" name to the closest + encloser. + + The first NSEC3 RR essentially proposes a possible closest encloser, + and proves that the particular encloser does, in fact, exist. The + second NSEC3 RR proves that the possible closest encloser is the + closest, and proves that QNAME (and any ancestors between QNAME and + the closest encloser) do not exist. + + These NSEC3 RRs are collectively referred to as the "closest encloser + proof" in the subsequent descriptions. + + For example, the closest encloser proof for the nonexistent + "alpha.beta.gamma.example." owner name might prove that + "gamma.example." is the closest encloser. This response would + contain the NSEC3 RR that matches "gamma.example.", and would also + contain the NSEC3 RR that covers "beta.gamma.example." (which is the + "next closer" name.) + + It is possible, when using Opt-Out (Section 6), to not be able to + prove the actual closest encloser because it is, or is part of an + insecure delegation covered by an Opt-Out span. In this case, + instead of proving the actual closest encloser, the closest provable + encloser is used. That is, the closest enclosing authoritative name + is used instead. In this case, the set of NSEC3 RRs used for this + proof is referred to as the "closest provable encloser proof." + +7.2.2. Name Error Responses + + To prove the nonexistence of QNAME a closest encloser proof and an + NSEC3 RR covering the (nonexistent) wildcard RR at the closest + encloser MUST be included in the response. This collection of (up + to) three NSEC3 RRs proves both that QNAME does not exist and that a + wildcard that could have matched QNAME also does not exist. + + For example, if "gamma.example." is the closest provable encloser to + QNAME, then a NSEC3 RR covering "*.gamma.example." is included in the + authority section of the response. + + + +Laurie, et al. Expires January 2, 2008 [Page 18] + +Internet-Draft nsec3 July 2007 + + +7.2.3. No Data Responses, QTYPE is not DS + + The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 + RR MUST NOT have the bits corresponding to either the QTYPE or CNAME + set in its Type Bit Maps field. + +7.2.4. No Data Responses, QTYPE is DS + + If there is an NSEC3 RR that matches QNAME, the server MUST return it + in the response. The bits corresponding with DS and CNAME MUST NOT + be set in the Type Bit Maps field of this NSEC3 RR. + + If no NSEC3 RR matches QNAME, the server MUST return a closest + provable encloser proof for QNAME. The NSEC3 RR that covers the + "next closer" name MUST have the Opt-Out bit set (note that this is + true by definition - if the Opt-Out bit is not set, something has + gone wrong). + + If a server is authoritative for both sides of a zone cut at QNAME, + the server MUST return the proof from the parent side of the zone + cut. + +7.2.5. Wildcard No Data Responses + + If there is a wildcard match for QNAME, but QTYPE is not present at + that name, the response MUST include a closest encloser proof for + QNAME and MUST include the NSEC3 RR that matches the wildcard. This + combination proves both that QNAME itself does not exist and that a + wildcard that matches QNAME does exist. Note that the closest + encloser to QNAME MUST be the immediate ancestor of the wildcard RR + (if this is not the case, then something has gone wrong). + +7.2.6. Wildcard Answer Responses + + If there is a wildcard match for QNAME and QTYPE, then, in addition + to the expanded wildcard RRSet returned in the answer section of the + response, proof that the wildcard match was valid must be returned. + + This proof is accomplished by proving that both QNAME does not exist, + and that the closest encloser of the QNAME and the immediate ancestor + of the wildcard are the same (i.e., the correct wildcard matched). + + To this end, the NSEC3 RR that covers the "next closer" name of the + immediate ancestor of the wildcard MUST be returned. It is not + necessary to return an NSEC3 RR that matches the closest encloser, as + the existence of this closest encloser is proven by the presence of + the expanded wildcard in the response. + + + + +Laurie, et al. Expires January 2, 2008 [Page 19] + +Internet-Draft nsec3 July 2007 + + +7.2.7. Referrals to Unsigned Subzones + + If there is an NSEC3 RR that matches the delegation name, then that + NSEC3 RR MUST be included in the response. The DS bit in the type + bit maps of the NSEC3 RR MUST NOT be set. + + If the zone is Opt-Out, then there may not be an NSEC3 RR + corresponding to the delegation. In this case, the closest provable + encloser proof MUST be included in the response. The included NSEC3 + RR that covers the "next closer" name for the delegation MUST have + the Opt-Out flag set to one. (Note that this will be the case unless + something has gone wrong). + +7.2.8. Responding to Queries for NSEC3 Owner Names + + The owner names of NSEC3 RRs are not represented in the NSEC3 RR + chain like other owner names. As a result, each NSEC3 owner name is + covered by another NSEC3 RR, effectively negating the existence of + the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR + can be proven by its RRSIG RRSet. + + If the following conditions are all true: + + o The QNAME equals the owner name of an existing NSEC3 RR, and + + o No RR types exist at the QNAME, nor at any descendant of QNAME. + + Then the response MUST be constructed as a Name Error response + (Section 7.2.2). Or, in other words, the authoritative name server + will act, as if the owner name of the NSEC3 RR did not exist. + + Note that NSEC3 RRs are returned as a result of an AXFR or IXFR + query. + +7.2.9. Server Response to a Run-time Collision + + If the hash of a non-existing QNAME collides with the owner name of + an existing NSEC3 RR, then the server will be unable to return a + response that proves that QNAME does not exist. In this case, the + server MUST return a response with an RCODE of 2 (server failure). + + Note that with the hash algorithm specified in this document, SHA-1, + such collisions are highly unlikely. + +7.3. Secondary Servers + + Secondary servers (and perhaps other entities) need to reliably + determine which NSEC3 parameters (i.e., hash, salt and iterations) + + + +Laurie, et al. Expires January 2, 2008 [Page 20] + +Internet-Draft nsec3 July 2007 + + + are present at every hashed owner name, in order to be able to choose + an appropriate set of NSEC3 RRs for negative responses. This is + indicated by an NSEC3PARAM RR present at the zone apex. + + If there are multiple NSEC3PARAM RRs present, there are multiple + valid NSEC3 chains present. The server must choose one of them, but + may use any criteria to do so. + +7.4. Zones Using Unknown Hash Algorithms + + Zones that are signed according to this specification, but are using + an unrecognized NSEC3 hash algorithm value, cannot be effectively + served. Such zones SHOULD be rejected when loading. Servers SHOULD + respond with RCODE=2 (server failure) responses when handling queries + that would fall under such zones. + +7.5. Dynamic Update + + A zone signed using NSEC3 may accept dynamic updates [RFC2136]. + However, NSEC3 introduces some special considerations for dynamic + updates. + + Adding and removing names in a zone MUST account for the creation or + removal of empty non-terminals. + + o When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs + corresponding to empty non-terminals created by that name MUST be + removed. Note that more than one name may be asserting the + existence of a particular empty non-terminal. + + o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs + MUST also be added for any empty non-terminals that are created. + That is, if there is not an existing NSEC3 RR matching an empty + non-terminal, it must be created and added. + + The presence of Opt-Out in a zone means that some additions or + delegations of names will not require changes to the NSEC3 RRs in a + zone. + + o When removing a delegation RRSet, if that delegation does not have + a matching NSEC3 RR, then it was opted out. In this case, nothing + further needs to be done. + + o When adding a delegation RRSet, if the "next closer" name of the + delegation is covered by an existing Opt-Out NSEC3 RR, then the + delegation MAY be added without modifying the NSEC3 RRs in the + zone. + + + + +Laurie, et al. Expires January 2, 2008 [Page 21] + +Internet-Draft nsec3 July 2007 + + + The presence of Opt-Out in a zone means that when adding or removing + NSEC3 RRs, the value of the Opt-Out flag that should be set in new or + modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of + basic rules to resolve the ambiguity. + + The central concept to these rules is that the state of the Opt-Out + flag of the covering NSEC3 RR is preserved. + + o When removing an NSEC3 RR, the value of the Opt-Out flag for the + previous NSEC3 RR (the one whose next hashed owner name is + modified) should not be changed. + + o When adding an NSEC3 RR, the value of the Opt-Out flag is set to + the value of the Opt-Out flag of the NSEC3 RR that previously + covered the owner name of the NSEC3 RR. That is, the now previous + NSEC3 RR. + + If the zone in question is consistent with its use of the Opt-Out + flag (that is, all NSEC3 RRs in the zone have the same value for the + flag) then these rules will retain that consistency. If the zone is + not consistent in the use of the flag (i.e., a partially Opt-Out + zone), then these rules will not retain the same pattern of use of + the Opt-Out flag. + + For zones that partially use the Opt-Out flag, if there is a logical + pattern for that use, the pattern could be maintained by using a + local policy on the server. + + +8. Validator Considerations + +8.1. Responses with Unknown Hash Types + + A validator MUST ignore NSEC3 RRs with unknown hash types. The + practical result of this is that responses containing only such NSEC3 + RRs will generally be considered bogus. + +8.2. Verifying NSEC3 RRs + + A validator MUST ignore NSEC3 RRs with a Flag fields value other than + zero or one. + + A validator MAY treat a response as bogus if the response contains + NSEC3 RRs that contain different values for hash algorithm, + iterations, or salt from each other for that zone. + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 22] + +Internet-Draft nsec3 July 2007 + + +8.3. Closest Encloser Proof + + In order to verify a closest encloser proof, the validator MUST find + the longest name, X, such that + + o X is an ancestor of QNAME that is matched by an NSEC3 RR present + in the response. This is a candidate for the closest encloser. + And: + + o The name one label longer than X (but still an ancestor of--or + equal to--QNAME) is covered by an NSEC3 RR present in the + response. + + One possible algorithm for verifying this proof is as follows: + + 1. Set SNAME=QNAME. Clear the flag. + + 2. Check whether SNAME exists: + + * If there is no NSEC3 RR in the response that matches SNAME + (i.e., an NSEC3 RR whose owner name is the same as the hash of + SNAME, prepended as a single label to the zone name), clear + the flag. + + * If there is an NSEC3 RR in the response that covers SNAME, set + the flag. + + * If there is a matching NSEC3 RR in the response and the flag + was set, then the proof is complete, and SNAME is the closest + encloser. + + * If there is a matching NSEC3 RR in the response, but the flag + is not set, then the response is bogus. + + 3. Truncate SNAME by one label from the left, go to step 2. + + Once the closest encloser has been discovered, the validator MUST + check that the NSEC3 RR that has the closest encloser as the original + owner name is from the proper zone. The DNAME type bit must not be + set and the NS type bit may only be set if the SOA type bit is set. + If this is not the case, it would be an indication that an attacker + is using them to falsely deny the existence of RRs for which the + server is not authoritative. + + In the following descriptions, the phrase "a closest (provable) + encloser proof for X" means that the algorithm above (or an + equivalent algorithm) proves that X does not exist by proving that an + ancestor of X is its closest encloser. + + + +Laurie, et al. Expires January 2, 2008 [Page 23] + +Internet-Draft nsec3 July 2007 + + +8.4. Validating Name Error Responses + + A validator MUST verify that there is a closest encloser proof for + QNAME present in the response and that there is an NSEC3 RR that + covers the wildcard at the closest encloser (i.e., the name formed by + prepending the asterisk label to the closest encloser.) + +8.5. Validating No Data Responses, QTYPE is not DS + + The validator MUST verify that an NSEC3 RR that matches QNAME is + present and that both the QTYPE and the CNAME type are not set in its + Type Bit Maps field. + + Note that this test also covers the case where the NSEC3 RR exists + because it corresponds to an empty non-terminal, in which case the + NSEC3 RR will have an empty Type Bit Maps field. + +8.6. Validating No Data Responses, QTYPE is DS + + If there is an NSEC3 RR that matches QNAME present in the response, + then that NSEC3 RR MUST NOT have the bits corresponding to DS and + CNAME set in its Type Bit Maps field. + + If there is no such NSEC3 RR, then the validator MUST verify that a + closest provable encloser proof for QNAME is present in the response, + and that the NSEC3 RR that covers the "next closer" name has the Opt- + Out bit set. + +8.7. Validating Wildcard No Data Responses + + The validator MUST verify a closest encloser proof for QNAME and MUST + find an NSEC3 RR present in the response that matches the wildcard + name generated by prepending the asterisk label to the closest + encloser. Furthermore, the bits corresponding to both QTYPE and + CNAME MUST NOT be set in the wildcard matching NSEC3 RR. + +8.8. Validating Wildcard Answer Responses + + The verified wildcard answer RRSet in the response provides the + validator with a (candidate) closest encloser for QNAME. This + closest encloser is the immediate ancestor to the generating + wildcard. + + Validators MUST verify that there is an NSEC3 RR that covers the + "next closer" name to QNAME present in the response. This proves + that QNAME itself did not exist and that the correct wildcard was + used to generate the response. + + + + +Laurie, et al. Expires January 2, 2008 [Page 24] + +Internet-Draft nsec3 July 2007 + + +8.9. Validating Referrals to Unsigned Subzones + + The delegation name in a referral is the owner name of the NS RRSet + present in the authority section of the referral response. + + If there is an NSEC3 RR present in the response that matches the + delegation name, then the validator MUST ensure that the NS bit is + set and that the DS bit is not set in the Type Bit Maps field of the + NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from + the correct (i.e., parent) zone. This is done by ensuring that the + SOA bit is not set in the Type Bit Maps field of this NSEC3 RR. + + Note that the presence of an NS bit implies the absence of a DNAME + bit, so there is no need to check for the DNAME bit in the Type Bit + Maps field of the NSEC3 RR. + + If there is no NSEC3 RR present that matches the delegation name, + then the validator MUST verify a closest provable encloser proof for + the delegation name. The validator MUST verify that the Opt-Out bit + is set in the NSEC3 RR that covers the "next closer" name to the + delegation name. + + +9. Resolver Considerations + +9.1. NSEC3 Resource Record Caching + + Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs + when returning responses that contain them. In DNSSEC [RFC4035], in + many cases it is possible to find the correct NSEC RR to return in a + response by name (e.g., when returning a referral, the NSEC RR will + always have the same owner name as the delegation.) With this + specification, that will not be true, nor will a cache be able to + calculate the name(s) of the appropriate NSEC3 RR(s). + Implementations may need to use new methods for caching and + retrieving NSEC3 RRs. + +9.2. Use of the AD Bit + + The AD bit, as defined by [RFC4035], MUST NOT be set when returning a + response containing a closest (provable) encloser proof in which the + NSEC3 RR that covers the "next closer" name has the Opt-Out bit set. + + This rule is based on what this closest encloser proof actually + proves: names that would be covered by the Opt-Out NSEC3 RR may or + may not exist as insecure delegations. As such, not all the data in + responses containing such closest encloser proofs will have been + cryptographically verified, so the AD bit cannot be set. + + + +Laurie, et al. Expires January 2, 2008 [Page 25] + +Internet-Draft nsec3 July 2007 + + +10. Special Considerations + +10.1. Domain Name Length Restrictions + + Zones signed using this specification have additional domain name + length restrictions imposed upon them. In particular, zones with + names that, when converted into hashed owner names, exceed the 255 + octet length limit imposed by [RFC1035] cannot use this + specification. + + The actual maximum length of a domain name in a particular zone + depends on both the length of the zone name (versus the whole domain + name) and the particular hash function used. + + As an example, SHA-1 produces a hash of 160 bits. The base-32 + encoding of 160 bits results in 32 characters. The 32 characters are + prepended to the name of the zone as a single label, which includes a + length field of a single octet. The maximum length of the zone name, + when using SHA-1, is 222 octets (255 - 33). + +10.2. DNAME at the Zone Apex + + The DNAME specification [RFC2672] section 3 has a 'no-descendants' + limitation. If a DNAME RR is present at node N, there MUST be no + data at any descendant of N. + + If N is the apex of the zone, there will be NSEC3 and RRSIG types + present at descendants of N. This specification updates the DNAME + specification to allow NSEC3 and RRSIG types at descendants of the + apex regardless of the existence of DNAME at the apex. + +10.3. Iterations + + Setting the number of iterations used allows the zone owner to choose + the cost of computing a hash, and so the cost of generating a + dictionary. Note that this is distinct from the effect of salt, + which prevents the use of a single precomputed dictionary for all + time. + + Obviously the number of iterations also affects the zone owner's cost + of signing and serving the zone as well as the validator's cost of + verifying responses from the zone. We therefore impose an upper + limit on the number of iterations. We base this on the number of + iterations that approximates the cost of verifying an RRSet. + + The limits, therefore, are based on the size of the smallest zone + signing key, rounded up to the nearest table value (or rounded down + if the key is larger than the largest table value.) + + + +Laurie, et al. Expires January 2, 2008 [Page 26] + +Internet-Draft nsec3 July 2007 + + + A zone owner MUST NOT use a value higher than shown in the table + below for iterations for the given key size. A resolver MAY treat a + response with a higher value as insecure, after the validator has + verified that the signature over the NSEC3 RR is correct. + + +----------+------------+ + | Key Size | Iterations | + +----------+------------+ + | 1024 | 150 | + | 2048 | 500 | + | 4096 | 2,500 | + +----------+------------+ + + This table is based on an approximation of the ratio between the cost + of an SHA-1 calculation and the cost of an RSA verification for keys + of size 1024 bits (150 to 1), 2048 bits (500 to 1) and 4096 bits + (2500 to 1). + + The ratio between SHA-1 calculation and DSA verification is higher + (1500 to 1 for keys of size 1024). A higher iteration count degrades + performance, while DSA verification is already more expensive than + RSA for the same key size. Therefore the values in the table MUST be + used independent of the key algorithm. + +10.4. Transitioning a Signed Zone from NSEC to NSEC3 + + When transitioning an already signed and trusted zone to this + specification, care must be taken to prevent client validation + failures during the process. + + The basic procedure is as follows: + + 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases + described in Section 2. The actual method for safely and + securely changing the DNSKEY RRSet of the zone is outside the + scope of this specification. However, the end result MUST be + that all DS RRs in the parent use the specified algorithm + aliases. + + After this transition is complete, all NSEC3-unaware clients will + treat the zone as insecure. At this point, the authoritative + server still returns negative and wildcard responses that contain + NSEC RRs. + + 2. Add signed NSEC3 RRs to the zone, either incrementally or all at + once. If adding incrementally, then the last RRSet added MUST be + the NSEC3PARAM RRSet. + + + + +Laurie, et al. Expires January 2, 2008 [Page 27] + +Internet-Draft nsec3 July 2007 + + + 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to + serving negative and wildcard responses with NSEC3 RRs according + to this specification. + + 4. Remove the NSEC RRs either incrementally or all at once. + +10.5. Transitioning a Signed Zone From NSEC3 to NSEC + + To safely transition back to a DNSSEC [RFC4035] signed zone, simply + reverse the procedure above: + + 1. Add NSEC RRs incrementally or all at once. + + 2. Remove the NSEC3PARAM RRSet. This will signal the server to use + the NSEC RRs for negative and wildcard responses. + + 3. Remove the NSEC3 RRs either incrementally or all at once. + + 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. + After this transition is complete, all NSEC3-unaware clients will + treat the zone as secure. + + +11. IANA Considerations + + This document updates the IANA registry "DOMAIN NAME SYSTEM + PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub- + registry "TYPES", by defining two new types. Section 3 defines the + NSEC3 RR type NN, (value 50 suggested). Section 4 defines the + NSEC3PARAM RR type MM (value 51 suggested). + + This document updates the IANA registry "DNS SECURITY ALGORITHM + NUMBERS - per [RFC4035]" + http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2 + defines the aliases DSA-NSEC3-SHA1 (XX) and RSASHA1-NSEC3-SHA1 (YY) + for respectively existing registrations DSA and RSASHA1 in + combination with NSEC3 hash algorithm SHA1. + + Since these algorithm numbers are aliases for existing DNSKEY + algorithm numbers, the flags that exist for the original algorithm + are valid for the alias algorithm. + + This document creates a new IANA registry for NSEC3 flags. This + registry should be named "DNSSEC NSEC3 Flags". The initial contents + of this registry are: + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 28] + +Internet-Draft nsec3 July 2007 + + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + | | | | | | | |Opt| + | | | | | | | |Out| + +---+---+---+---+---+---+---+---+ + + bit 7 is the Opt-Out flag. + + bits 0 - 6 are available for assignment. + + Assignment of additional NSEC3 Flags in this registry requires IETF + Standards Action [RFC2434]. + + This document creates a new IANA registry for NSEC3PARAM flags. This + registry should be named "DNSSEC NSEC3PARAM Flags". The initial + contents of this registry are: + + 0 1 2 3 4 5 6 7 + +---+---+---+---+---+---+---+---+ + | | | | | | | | 0 | + +---+---+---+---+---+---+---+---+ + + bit 7 is reserved and must be 0. + + bits 0 - 6 are available for assignment. + + Assignment of additional NSEC3PARAM Flags in this registry requires + IETF Standards Action [RFC2434]. + + Finally, this document creates a new IANA registry for NSEC3 hash + algorithms. This registry should be named "DNSSEC NSEC3 Hash + Algorithms". The initial contents of this registry are: + + 0 is Reserved + + 1 is SHA-1. + + 2-255 Available for assignment + + Assignment of additional NSEC3 hash algorithms in this registry + requires IETF Standards Action [RFC2434]. + + +12. Security Considerations + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 29] + +Internet-Draft nsec3 July 2007 + + +12.1. Hashing Considerations + +12.1.1. Dictionary Attacks + + The NSEC3 RRs are still susceptible to dictionary attacks (i.e. the + attacker retrieves all the NSEC3 RRs, then calculates the hashes of + all likely domain names, comparing against the hashes found in the + NSEC3 RRs, and thus enumerating the zone). These are substantially + more expensive than enumerating the original NSEC RRs would have + been, and in any case, such an attack could also be used directly + against the name server itself by performing queries for all likely + names, though this would obviously be more detectable. The expense + of this off-line attack can be chosen by setting the number of + iterations in the NSEC3 RR. + + Zones are also susceptible to a pre-calculated dictionary attack -- + that is, a list of hashes for all likely names is computed once, then + NSEC3 RR is scanned periodically and compared against the precomputed + hashes. This attack is prevented by changing the salt on a regular + basis. + + The salt SHOULD be at least 64 bits long and unpredictable, so that + an attacker cannot anticipate the value of the salt and compute the + next set of dictionaries before the zone is published. + +12.1.2. Collisions + + Hash collisions between QNAME and the owner name of an NSEC3 RR may + occur. When they do, it will be impossible to prove the non- + existence of the colliding QNAME. However, with SHA-1, this is + highly unlikely (on the order of 1 in 2^160). Note that DNSSEC + already relies on the presumption that a cryptographic hash function + is second pre-image resistant, since these hash functions are used + for generating and validating signatures and DS RRs. + +12.1.3. Transitioning to a New Hash Algorithm + + Since validators are instructed to ignore NSEC3 RRs with unknown hash + algorithms, simply using a new or unknown hash algorithm directly + will lead to validation failures with clients that understand NSEC3 + but do not understand the hash algorithm. + + When transitioning to a new hash algorithm, care must be taken to + prevent client validation failures during the process. This is done + using a similar procedure to transitioning from NSEC to NSEC3 + (Section 10.4) + + The basic procedure is as follows: + + + +Laurie, et al. Expires January 2, 2008 [Page 30] + +Internet-Draft nsec3 July 2007 + + + 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases + allocated for the new NSEC3 hash algorithm. The actual method + for safely and securely changing the DNSKEY RRSet of the zone is + outside the scope of this specification. However, the end result + MUST be that all DS RRs in the parent use the specified algorithm + aliases. + + After this transition is complete, all clients unaware of the new + hash algorithm will treat the zone as insecure. At this point, + the authoritative server still returns negative and wildcard + responses that contain NSEC3 RRs with the known hash function. + + 2. Add signed NSEC3 RRs with the new hash algorithm to the zone, + either incrementally or all at once. If adding incrementally, + then the last RRSet added MUST be the NSEC3PARAM RRSet containing + the new hash algorithm. + + 3. Upon the addition of the NSEC3PARAM RR containing the new hash + algorithm, and after the removal of the NSEC3PARAM RR containing + the old hash algorithm, the server switches to serving negative + and wildcard responses with NSEC3 RRs containing the new hash + algorithm. + + 4. Remove the NSEC3 RRs containing the old hash algorithm either + incrementally or all at once. + +12.1.4. Using High Iteration Values + + Since validators should treat responses containing NSEC3 RRs with + high iteration values as insecure, presence of just one signed NSEC3 + RR with a high iteration value in a zone provides attackers with a + possible downgrade attack. + + The attack is simply to remove any existing NSEC3 RRs from a + response, and replace or add a single (or multiple) NSEC3 RR that + uses a high iterations value to the response. Validators will then + be forced to treat the response as insecure. This attack would be + effective only when all of following conditions are met: + + o There is at least one signed NSEC3 RR that uses a high iterations + value present in the zone. + + o The attacker has access to one or more of these NSEC3 RRs. This + is trivially true when the NSEC3 RRs with high iterations values + are being returned in typical responses, but may also be true if + the attacker can access the zone via AXFR or IXFR queries, or any + other methodology. + + + + +Laurie, et al. Expires January 2, 2008 [Page 31] + +Internet-Draft nsec3 July 2007 + + + Using a high number of iterations also introduces an additional + denial-of-service opportunity against servers, since servers must + calculate several hashes per negative or wildcard response. + +12.2. Opt-Out Considerations + + The Opt-Out Flag (O) allows for unsigned names, in the form of + delegations to unsigned zones, to exist within an otherwise signed + zone. All unsigned names are, by definition, insecure, and their + validity or existence cannot be cryptographically proven. + + In general: + + o Resource records with unsigned names (whether existing or not) + suffer from the same vulnerabilities as RRs in an unsigned zone. + These vulnerabilities are described in more detail in [RFC3833] + (note in particular sections 2.3, "Name Chaining" and 2.6, + "Authenticated Denial of Domain Names"). + + o Resource records with signed names have the same security whether + or not Opt-Out is used. + + Note that with or without Opt-Out, an insecure delegation may be + undetectably altered by an attacker. Because of this, the primary + difference in security when using Opt-Out is the loss of the ability + to prove the existence or nonexistence of an insecure delegation + within the span of an Opt-Out NSEC3 RR. + + In particular, this means that a malicious entity may be able to + insert or delete RRs with unsigned names. These RRs are normally NS + RRs, but this also includes signed wildcard expansions (while the + wildcard RR itself is signed, its expanded name is an unsigned name). + + Note that being able to add a delegation is functionally equivalent + to being able to add any RR type: an attacker merely has to forge a + delegation to name server under his/her control and place whatever + RRs needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. + In particular, zone signing tools SHOULD NOT default to using Opt- + Out, and MAY choose to not support Opt-Out at all. + +12.3. Other Considerations + + Walking the NSEC3 RRs will reveal the total number of RRs in the zone + (plus empty non-terminals), and also what types there are. This + + + +Laurie, et al. Expires January 2, 2008 [Page 32] + +Internet-Draft nsec3 July 2007 + + + could be mitigated by adding dummy entries, but certainly an upper + limit can always be found. + + +13. References + +13.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + + + +Laurie, et al. Expires January 2, 2008 [Page 33] + +Internet-Draft nsec3 July 2007 + + + Extensions", RFC 4035, March 2005. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + +13.2. Informative References + + [I-D.jas-dnsext-no] + Josefsson, S., "Authenticating denial of existence in DNS + with minimum disclosure", draft-jas-dnsext-no-00 (work in + progress), July 2000. + + [I-D.laurie-dnsext-nsec2v2] + Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", + draft-laurie-dnsext-nsec2v2-00 (work in progress), + December 2004. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification Version 2.0", RFC 2898, September 2000. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + + [RFC4956] Arends, R., Kosters, M., and D. Blacka, "DNS Security + (DNSSEC) Opt-In", RFC 4956, July 2007. + + +Appendix A. Example Zone + + This is a zone showing its NSEC3 RRs. They can also be used as test + vectors for the hash algorithm. + + The overall TTL and class are specified in the SOA RR, and are + subsequently omitted for clarity. + + The zone is preceded by a list that contains the hashes of the + original ownernames. + + + ; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom + ; H(a.example) = 35mthgpgcu1qg68fab165klnsnk3dpvl + ; H(ai.example) = gjeqe526plbf1g8mklp59enfd789njgi + + + +Laurie, et al. Expires January 2, 2008 [Page 34] + +Internet-Draft nsec3 July 2007 + + + ; H(ns1.example) = 2t7b4g4vsa5smi47k61mv5bv1a22bojr + ; H(ns2.example) = q04jkcevqvmu85r014c7dkba38o0ji5r + ; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h + ; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en + ; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 + ; H(y.w.example) = ji6neoaepv8b5o6k4ev33abha8ht9fgc + ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s + ; H(xx.example) = t644ebqk9bibcna874givr6joj62mlhv + ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example) + ; = kohar7mbb8dc2ce8a9qvl8hon4k53uhi + example. 3600 IN SOA ns1.example. bugs.x.w.example. 1 3600 300 ( + 3600000 3600 ) + RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ + ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ + rynLZNqsbLm40Q== ) + NS ns1.example. + NS ns2.example. + RRSIG NS 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM + gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 + JpiZcff2Cj2B0w== ) + MX 1 xx.example. + RRSIG MX 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + jsGuTpXTTrZHzUKnViUpJ8YyGNpDd6n/sy2g + HnSC0nj2jPxTC5VENLo3GxSpCSA5DlAz57p+ + RllUJk3DWktkjw== ) + DNSKEY 256 3 133 ( + AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU + 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL + ExXT48OGGdbfIme5 ) + DNSKEY 257 3 133 ( + AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX + cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 + zsYKWJ7BvR2894hX ) + RRSIG DNSKEY 133 1 3600 20150420235959 ( + 20051021000000 22088 example. + Xpo9ptByXb8M1JR1i0KuRmKGc/YeOLcc6Ptn + RJOx6ADLSL2mU6AYX5tAJRMTKTXk6waLIaxu + liqUBOkCjLUZMw== ) + NSEC3PARAM 1 0 12 aabbccdd + RRSIG NSEC3PARAM 133 1 3600 20150420235959 ( + 20051021000000 62827 example. + pwUfI8cF9JJn5dTWI24nJy92HYrRPtPgHtgi + jAlKx9QELe68pLKuGU/8Sf87kyV7yMXJYVhf + + + +Laurie, et al. Expires January 2, 2008 [Page 35] + +Internet-Draft nsec3 July 2007 + + + HIB8wmHllsqM+g== ) + 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( + 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS + SOA NSEC3PARAM RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF + xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix + 4eI9tMfaTVgehQ== ) + 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 + RRSIG A 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + GtJTFlvT5eYaK3rNUPQjpCKoIefvWZxQrDxU + jYsmoIWdLOVOuD5ZSDDQA3anDctOHdA/XbXn + o2uyWso1OzVlgg== ) + NSEC3 1 1 12 aabbccdd ( + 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + fJER1Z3nGoN0HmZm99lqNLSpIf7jLXTMoGm2 + k4gIwlc0R4DztJp6Sq37OV6XnGdre4MfgRpB + mAcgpPWC5A5eiw== ) + 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( + 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + os2mHXmu3bsaWu0XzT1R61fHL1a3LvyQ6bKq + oKokSyJ0ch0jBqEdxP2BqUe0WW0ja19fQGCG + 8Bc+L9MbAeYsrw== ) + 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( + b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX + r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T + vYN3GgN0W/0WHQ== ) + a.example. NS ns1.a.example. + NS ns2.a.example. + DS 58470 5 1 ( + 3079F1593EBAD6DC121E202A8B766A6A4837206C ) + RRSIG DS 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + qxw4j5LNe70UDu121YqAaqQjyjYbdKNd/4bE + nH0kjQswuiGs9EuArCBhcWocWQDBku+A4HMH + JdLqJr5p4JctLg== ) + ns1.a.example. A 192.0.2.5 + ns2.a.example. A 192.0.2.6 + ai.example. A 192.0.2.9 + + + +Laurie, et al. Expires January 2, 2008 [Page 36] + +Internet-Draft nsec3 July 2007 + + + RRSIG A 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag + lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 + BXfXAqURwLqznA== ) + HINFO "KLH-10" "ITS" + RRSIG HINFO 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + BuDv+No06VEcIsEnvBdjdKm6kxQGrhOgKEKb + Gsb8DJRjY7Lia+YG2//s6OlOIfxPmLlLiYpA + i3q2sEjTJhocGQ== ) + AAAA 2001:db8:0:0:0:0:f00:baa9 + RRSIG AAAA 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M + hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x + 2ruyuN0zC+PABA== ) + b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( + gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + GWDmUk8Sv0dxy/UZFol4Ss7Wz3wBiongcnVy + strNODWwdnoO9z6pDh8JLk58ExfEgXm79i4b + Ma6C/s/bkk1LvA== ) + c.example. NS ns1.c.example. + NS ns2.c.example. + ns1.c.example. A 192.0.2.7 + ns2.c.example. A 192.0.2.8 + gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( + ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA + RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + DCkJyHQSgA9HNA2AQUENLfmAdAqQ4iIcuqZV + pF2x/i1UyWIBuV25iESs4hhwRVIU5uMZaBGE + lNwi0H6f66BpOA== ) + ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( + k8udemvp1j2f7eg6jebps17vp3n8i58h ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + fvKWkD3lXNLyUn0/gN+i3Z8301oRujSFFrJy + SfAPS2Q1bw1Q5eQoy7IE+ZtUVO15ha6C9cUh + CArJyEk247MADA== ) + k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( + kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + IKJfInxfypsDiXKgT6HDvCPEIBu9lZCc0CWl + + + +Laurie, et al. Expires January 2, 2008 [Page 37] + +Internet-Draft nsec3 July 2007 + + + c46+Gj/Jrg1NBkSJkKMjCERp1HT8tKU+zYp5 + Kyio/cddEaa5Gg== ) + kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( + q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + j+XRmZBLAu/s0Ah49x7SChH2VsXAMD3nJE0m + UEjzrjFxkdjhdIAFNlvPMn8gy6mIVe5eNc3r + 4+2KaJUEJhyUEQ== ) + ns1.example. A 192.0.2.1 + RRSIG A 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + ratEKfeWD/pJJHO/XqEINvOp3so7pn9Pphxn + fRiCOVsa527M/ucRcQqGYCF0CN4jAXhW+6BS + ZzT0om+VdioRmg== ) + ns2.example. A 192.0.2.2 + RRSIG A 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + mW/DJMbQyD5y5C+a70vWyIWZyQ+Xg1zzkWHX + w3jfqmePgpdJnMrpGOcRIpy5irCFWiCwTp2o + cPT+k0ccpxtkLQ== ) + q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( + r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc + kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC + Wu6EvgCXrflgiQ== ) + r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( + t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + SzeyaiFOy9dFO1RKHAK4uVCb5GF4rNnxFMXu + 6hpM44cmLcDgshlnG1CwkkcihfKOiPIBWd7I + bGhsbhqrBrn5Dg== ) + t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( + 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA + RRSIG ) + RRSIG NSEC3 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + hkULY2VaEg8lvI0cf+YkUB0rvOORGMGJnfms + h2OecPBYfI9XGUBvqgIyNpNpK3nIFoW/VNO+ + 3H+6P1NzivDmog== ) + *.w.example. MX 1 ai.example. + RRSIG MX 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR + c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq + + + +Laurie, et al. Expires January 2, 2008 [Page 38] + +Internet-Draft nsec3 July 2007 + + + a7Xfz/f9xzvSTw== ) + x.w.example. MX 1 xx.example. + RRSIG MX 133 3 3600 20150420235959 20051021000000 ( + 62827 example. + BLSDMos8kYR7+2U7iwwdqdhU82hzq0s57xtw + F08tWU/d19jrNO6LdWfBL/FJ8zL8ZpEjhh6b + 8cj0f5yQOUyShw== ) + x.y.w.example. MX 1 xx.example. + RRSIG MX 133 4 3600 20150420235959 20051021000000 ( + 62827 example. + GPzELyUCxrnyep8uMcqthUXjTqYBmgeaveb9 + 2vQgzUyPLLamNN/YqMHr6tGQNxeMAhclxUSQ + eoCggUBVhFfB1Q== ) + xx.example. A 192.0.2.10 + RRSIG A 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + Sz+fPqY8II1VDq+dY48Q40dq1aoBR2RAuhKg + QNKXEYcULtJo/hxxfEAkJSNBKU5QnHpnnT9L + jqaSdob7ZhdxHg== ) + HINFO "KLH-10" "TOPS-20" + RRSIG HINFO 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + YJFwmD0By0NpGEvO1nE1ZTH10XrmpKnVuAEI + cAxLLHyPs3qyGQdDEG7sQX5+PfiOGZrNmZef + 8NgQhW8kGEgN1Q== ) + AAAA 2001:db8:0:0:0:0:f00:baaa + RRSIG AAAA 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + VAJBlXoTOScrIM6yPlDsd9o05v39qIzFnemR + 2vgw1s4l8maJVWi9IHEg8oiypJvGwSCP1nFs + EOlXyNFQJ0fWGA== ) + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1. Name Error + + An authoritative name error. The NSEC3 RRs prove that the name does + not exist and that there is no wildcard RR that should have been + expanded. + +;; Header: QR AA DO RCODE=3 +;; +;; Question +a.c.x.w.example. IN A + + + +Laurie, et al. Expires January 2, 2008 [Page 39] + +Internet-Draft nsec3 July 2007 + + +;; Answer +;; (empty) + +;; Authority + +example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( + 3600000 3600 ) +example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ + ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ + rynLZNqsbLm40Q== ) + +;; NSEC3 RR that covers the "next closer" name (c.x.w.example) +;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh + +0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( + 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS + SOA NSEC3PARAM RRSIG ) +0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF + xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix + 4eI9tMfaTVgehQ== ) + +;; NSEC3 RR that matches the closest encloser (x.w.example) +;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 + +b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( + gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) +b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + GWDmUk8Sv0dxy/UZFol4Ss7Wz3wBiongcnVy + strNODWwdnoO9z6pDh8JLk58ExfEgXm79i4b + Ma6C/s/bkk1LvA== ) + +;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example) +;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m + +35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( + b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) +35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX + r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T + vYN3GgN0W/0WHQ== ) + +;; Additional + + + +Laurie, et al. Expires January 2, 2008 [Page 40] + +Internet-Draft nsec3 July 2007 + + +;; (empty) + + The query returned three NSEC3 RRs that prove that the requested data + does not exist and that no wildcard expansion applies. The negative + response is authenticated by verifying the NSEC3 RRs. The + corresponding RRSIGs indicate that the NSEC3 RRs are signed by an + "example" DNSKEY of algorithm 133 and with key tag 62827. The + resolver needs the corresponding DNSKEY RR in order to authenticate + this answer. + + One of the owner names of the NSEC3 RRs matches the closest encloser. + One of the NSEC3 RRs prove that there exists no longer name. One of + the NSEC3 RRs prove that there exists no wildcard RRSets that should + have been expanded. The closest encloser can be found by applying + the algorithm in section Section 8.3. + + In the above example, the name 'x.w.example' hashes to + 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might + be the closest encloser. To prove that 'c.x.w.example' and + '*.x.w.example' do not exist, these names are hashed to, + respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and + '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs + prove that these hashed owner names do not exist. + +B.2. No Data Error + + A "no data" response. The NSEC3 RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 41] + +Internet-Draft nsec3 July 2007 + + +;; Header: QR AA DO RCODE=0 +;; +;; Question +ns1.example. IN MX + +;; Answer +;; (empty) + +;; Authority +example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( + 3600000 3600 ) +example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ + ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ + rynLZNqsbLm40Q== ) + +;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set. + +2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( + 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) +2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + fJER1Z3nGoN0HmZm99lqNLSpIf7jLXTMoGm2 + k4gIwlc0R4DztJp6Sq37OV6XnGdre4MfgRpB + mAcgpPWC5A5eiw== ) +;; Additional +;; (empty) + + The query returned an NSEC3 RR that proves that the requested name + exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"), + but the requested RR type does not exist (type MX is absent in the + type code list of the NSEC3 RR), and was not a CNAME (type CNAME is + also absent in the type code list of the NSEC3 RR.) + +B.2.1. No Data Error, Empty Non-Terminal + + A "no data" response because of an empty non-terminal. The NSEC3 RR + proves that the name exists and that the requested RR type does not. + + + + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 42] + +Internet-Draft nsec3 July 2007 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + y.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( + 3600000 3600 ) + example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ + ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ + rynLZNqsbLm40Q== ) + + ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set. + + ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( + k8udemvp1j2f7eg6jebps17vp3n8i58h ) + ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + fvKWkD3lXNLyUn0/gN+i3Z8301oRujSFFrJy + SfAPS2Q1bw1Q5eQoy7IE+ZtUVO15ha6C9cUh + CArJyEk247MADA== ) + + ;; Additional + ;; (empty) + + + The query returned an NSEC3 RR that proves that the requested name + exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"), + but the requested RR type does not exist (Type A is absent in the + Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty + non-terminal proof using NSECs, this is identical to a No Data Error. + This example is solely mentioned to be complete. + +B.3. Referral to an Opt-Out Unsigned Zone + + The NSEC3 RRs prove that nothing for this delegation was signed. + There is no proof that the unsigned delegation exists. + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 43] + +Internet-Draft nsec3 July 2007 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.c.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + c.example. NS ns1.c.example. + NS ns2.c.example. + + ;; NSEC3 RR that covers the "next closer" name (c.example) + ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck + + 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( + b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) + 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + QrjOpXVIvodCw0O8uPMNA+yEeS/o3KKkEIPX + r5DoEShq2hymAsRTc/t9BvRKpcSTExyc5m3T + vYN3GgN0W/0WHQ== ) + + ;; NSEC3 RR that matches the closest encloser (example) + ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom + + 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( + 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS + SOA NSEC3PARAM RRSIG ) + 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF + xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix + 4eI9tMfaTVgehQ== ) + + ;; Additional + ns1.c.example. A 192.0.2.7 + ns2.c.example. A 192.0.2.8 + + + The query returned a referral to the unsigned "c.example." zone. The + response contains the closest provable encloser of "c.example" to be + "example", since the hash of "c.example" + ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR + and its Opt-Out bit is set. + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 44] + +Internet-Draft nsec3 July 2007 + + +B.4. Wildcard Expansion + + A query that was answered with a response containing a wildcard + expansion. The label count in the RRSIG RRSet in the answer section + indicates that a wildcard RRSet was expanded to produce this + response, and the NSEC3 RR proves that no "next closer" name exists + in the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 45] + +Internet-Draft nsec3 July 2007 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. MX 1 ai.example. + a.z.w.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR + c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq + a7Xfz/f9xzvSTw== ) + + ;; Authority + example. NS ns1.example. + example. NS ns2.example. + example. RRSIG NS 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM + gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 + JpiZcff2Cj2B0w== ) + + ;; NSEC3 RR that covers the "next closer" name (z.w.example) + ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 + + q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( + r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) + q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc + kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC + Wu6EvgCXrflgiQ== ) + + ;; Additional + ai.example. A 192.0.2.9 + ai.example. RRSIG A 133 2 3600 20150420235959 20051021000000 ( + 62827 example. + qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag + lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 + BXfXAqURwLqznA== ) + ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9 + ai.example. RRSIG AAAA 133 2 3600 20150420235959 ( + 20051021000000 62827 example. + m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M + hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x + 2ruyuN0zC+PABA== ) + + + + + +Laurie, et al. Expires January 2, 2008 [Page 46] + +Internet-Draft nsec3 July 2007 + + + The query returned an answer that was produced as a result of + wildcard expansion. The answer section contains a wildcard RRSet + expanded as it would be in a traditional DNS response. The RRSIG + Labels field value of 2 indicates that the answer is the result of + wildcard expansion, as the "a.z.w.example" name contains 4 labels. + This also shows that "w.example" exists, so there is no need for an + NSEC3 RR that matches the closest encloser. + + The NSEC3 RR proves that no closer match could have been used to + answer this query. + +B.5. Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC3 RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( + 3600000 3600 ) + example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ + ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ + rynLZNqsbLm40Q== ) + + ;; NSEC3 RR that matches the closest encloser (w.example) + ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h + + k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( + kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) + k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + IKJfInxfypsDiXKgT6HDvCPEIBu9lZCc0CWl + c46+Gj/Jrg1NBkSJkKMjCERp1HT8tKU+zYp5 + Kyio/cddEaa5Gg== ) + + ;; NSEC3 RR that covers the "next closer" name (z.w.example) + ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 + + + + +Laurie, et al. Expires January 2, 2008 [Page 47] + +Internet-Draft nsec3 July 2007 + + + q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( + r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) + q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + ktIfH8VRjEKYPB0Qf4EdTuSlYn4DVSRRaGWc + kVGmKzreEU5zs97CL8OQSa6C0JZX2yMBXijC + Wu6EvgCXrflgiQ== ) + + ;; NSEC3 RR that matches a wildcard at the closest encloser. + ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en + + r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( + t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) + r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + SzeyaiFOy9dFO1RKHAK4uVCb5GF4rNnxFMXu + 6hpM44cmLcDgshlnG1CwkkcihfKOiPIBWd7I + bGhsbhqrBrn5Dg== ) + + ;; Additional + ;; (empty) + + The query returned the NSEC3 RRs that prove that the requested data + does not exist and no wildcard RR applies. + +B.6. DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 48] + +Internet-Draft nsec3 July 2007 + + +;; Header: QR AA DO RCODE=0 +;; +;; Question +example. IN DS + +;; Answer +;; (empty) + +;; Authority +example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( + 3600000 3600 ) +example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( + 62827 example. + hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ + ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ + rynLZNqsbLm40Q== ) + +;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set. + +0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( + 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS + SOA NSEC3PARAM RRSIG ) +0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( + 20150420235959 20051021000000 62827 example. + rn2tv99+9StXbc7JaEnjT1+8I8f2vVOMOIbF + xzlrn94lQLxEOYxQR4SrxDRP4/fC54Jui0Ix + 4eI9tMfaTVgehQ== ) + +;; Additional +;; (empty) + + The query returned an NSEC3 RR showing that the requested was + answered by the server authoritative for the zone "example". The + NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3 + RR is from the apex of the child, not from the zone cut of the + parent. Queries for the "example" DS RRSet should be sent to the + parent servers (which are in this case the root servers). + + +Appendix C. Special Considerations + + The following paragraphs clarify specific behavior and explain + special considerations for implementations. + +C.1. Salting + + Augmenting original owner names with salt before hashing increases + the cost of a dictionary of pre-generated hash-values. For every bit + + + +Laurie, et al. Expires January 2, 2008 [Page 49] + +Internet-Draft nsec3 July 2007 + + + of salt, the cost of a precomputed dictionary doubles (because there + must be an entry for each word combined with each possible salt + value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of + salt, multiplying the cost by 2^2040. This means that an attacker + must, in practice, recompute the dictionary each time the salt is + changed. + + Including a salt, regardless of size, does not affect the cost of + constructing NSEC3 RRs. It does increase the size of the NSEC3 RR. + + There MUST be at least one complete set of NSEC3 RRs for the zone + using the same salt value. + + The salt SHOULD be changed periodically to prevent pre-computation + using a single salt. It is RECOMMENDED that the salt be changed for + every re-signing. + + Note that this could cause a resolver to see RRs with different salt + values for the same zone. This is harmless, since each RR stands + alone (that is, it denies the set of owner names whose hashes, using + the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 + RR) - it is only the server that needs a complete set of NSEC3 RRs + with the same salt in order to be able to answer every possible + query. + + There is no prohibition with having NSEC3 RRs with different salts + within the same zone. However, in order for authoritative servers to + be able to consistently find covering NSEC3 RRs, the authoritative + server MUST choose a single set of parameters (algorithm, salt, and + iterations) to use when selecting NSEC3 RRs. + +C.2. Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^(n/2) for a hash of length n + bits (i.e. 2^80 for SHA-1). Though this probability is extremely + low, the following paragraphs deal with avoiding collisions and + assessing possible damage in the event of an attack using hash + collisions. + +C.2.1. Avoiding Hash Collisions During Generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occurring, an alternative salt + MUST be chosen and all hash values MUST be regenerated. + + + + + +Laurie, et al. Expires January 2, 2008 [Page 50] + +Internet-Draft nsec3 July 2007 + + +C.2.2. Second Preimage Requirement Analysis + + A cryptographic hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + preimage X' != X such that hash(X) = hash(X'). The work factor for + finding a second preimage is of the order of 2^160 for SHA-1. To + mount an attack using an existing NSEC3 RR, an adversary needs to + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + either cause a security aware resolver to re-query for the non- + existent name, or to fail the initial query. Note that the adversary + can't mount this attack on an existing name but only on a name that + the adversary can't choose and does not yet exist. + + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 20 8735 0686 + Email: ben@links.org + + + Geoffrey Sisson + Nominet + Sandford Gate + Sandy Lane West + Oxford OX4 6LB + UNITED KINGDOM + + Phone: +44 1865 332211 + Email: geoff@nominet.org.uk + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 51] + +Internet-Draft nsec3 July 2007 + + + Roy Arends + Nominet + Sandford Gate + Sandy Lane West + Oxford OX4 6LB + UNITED KINGDOM + + Phone: +44 1865 332211 + Email: roy@nominet.org.uk + + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: davidb@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires January 2, 2008 [Page 52] + +Internet-Draft nsec3 July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Laurie, et al. Expires January 2, 2008 [Page 53] +