summaryrefslogtreecommitdiffstats
path: root/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt')
-rw-r--r--contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt2072
1 files changed, 2072 insertions, 0 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
new file mode 100644
index 0000000..cc3c276
--- /dev/null
+++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt
@@ -0,0 +1,2072 @@
+
+
+
+Network Working Group B. Laurie
+Internet-Draft G. Sisson
+Expires: December 3, 2005 Nominet
+ R. Arends
+ Telematica Instituut
+ june 2005
+
+
+ DNSSEC Hash Authenticated Denial of Existence
+ draft-ietf-dnsext-nsec3-02
+
+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 December 3, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
+ used to provide authenticated denial of existence of DNS ownernames
+ and types; however, it permits any user to traverse a zone and obtain
+ a listing of all ownernames.
+
+ A complete zone file can be used either directly as a source of
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 1]
+
+Internet-Draft nsec3 june 2005
+
+
+ probable e-mail addresses for spam, or indirectly as a key for
+ multiple WHOIS queries to reveal registrant data which many
+ registries (particularly in Europe) may be under strict legal
+ obligations to protect. Many registries therefore prohibit copying
+ of their zone file; however the use of NSEC RRs renders policies
+ unenforceable.
+
+ This document proposes a scheme which obscures original ownernames
+ while permitting authenticated denial of existence of non-existent
+ names. Non-authoritative delegation point NS RR types may be
+ excluded.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
+ 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5
+ 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6
+ 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6
+ 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7
+ 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7
+ 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7
+ 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7
+ 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8
+ 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9
+ 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9
+ 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10
+ 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10
+ 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11
+ 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11
+ 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
+ 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12
+ 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14
+ 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14
+ 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14
+ 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16
+ 10.2 Informative References . . . . . . . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
+ A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 2]
+
+Internet-Draft nsec3 june 2005
+
+
+ B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23
+ B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23
+ B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25
+ B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26
+ B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28
+ B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29
+ B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30
+ B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31
+ B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
+ B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34
+ B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35
+ Intellectual Property and Copyright Statements . . . . . . . . 37
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 3]
+
+Internet-Draft nsec3 june 2005
+
+
+1. Introduction
+
+ The DNS Security Extensions (DNSSEC) introduced the NSEC Resource
+ Record (RR) for authenticated denial of existence. This document
+ introduces a new RR as an alternative to NSEC that provides measures
+ against zone traversal and allows for gradual expansion of
+ delegation-centric zones.
+
+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 introduced a
+ side-effect in that the contents of a zone can be enumerated. This
+ property introduces undesired policy issues.
+
+ A second problem was the requirement that the existence of all record
+ types in a zone - including delegation point NS record types - must
+ be accounted for, despite the fact that delegation point NS RRsets
+ are not authoritative and not signed. This requirement has a side-
+ effect that the overhead of delegation-centric signed zones is not
+ related to the increase in security of subzones. This requirement
+ does not allow delegation-centric zones size to grow in relation to
+ the growth of signed subzones.
+
+ In the past, solutions have been proposed as a measure against these
+ side effects but at the time were regarded as secondary over the need
+ to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter)
+ a graceful transition path to future enhancements is introduced,
+ while current DNSSEC deployment can continue. This document presents
+ the NSEC3 Resource Record which mitigates these issues with the NSEC
+ RR.
+
+ The reader is assumed to be familiar with the basic DNS concepts
+ described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
+ that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
+ [RFC2308].
+
+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 RFC 2119 [RFC2119].
+
+1.3 Terminology
+
+ In this document the term "original ownername" refers to a standard
+ ownername. Because this proposal uses the result of a hash function
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 4]
+
+Internet-Draft nsec3 june 2005
+
+
+ over the original (unmodified) ownername, this result is referred to
+ as "hashed ownername".
+
+ "Canonical ordering of the zone" means the order in which hashed
+ ownernames are arranged according to their numerical value, treating
+ the leftmost (lowest numbered) byte as the most significant byte.
+
+2. The NSEC3 Resource Record
+
+ The NSEC3 RR provides Authenticated Denial of Existence for DNS
+ Resource Record Sets.
+
+ The NSEC3 Resource Record lists RR types present at the NSEC3 RR's
+ original ownername. It includes the next hashed ownername in the
+ canonical ordering of the zone. The complete set of NSEC3 RRs in a
+ zone indicates which RRsets exist for the original ownername of the
+ RRset and form a chain of hashed ownernames in the zone. This
+ information is used to provide authenticated denial of existence for
+ DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation
+ point NS RRsets can optionally be excluded. To provide protection
+ against zone traversal, the ownernames used in the NSEC3 RR are
+ cryptographic hashes of the original ownername prepended 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 ownername.
+
+ The ownername for the NSEC3 RR is the base32 encoding of the hashed
+ ownername.
+
+ The type value for the NSEC3 RR is XX.
+
+ The NSEC3 RR RDATA format is class independent.
+
+ The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
+ field. This is in the spirit of negative caching [RFC2308].
+
+2.1 NSEC3 RDATA Wire Format
+
+ The RDATA of the NSEC3 RR is as shown below:
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 5]
+
+Internet-Draft nsec3 june 2005
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|Hash Function| Iterations |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Salt Length | Salt /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Next Hashed Ownername /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Type Bit Maps /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+2.1.1 The Authoritative Only Flag Field
+
+ The Authoritative Only Flag field indicates whether the Type Bit Maps
+ include delegation point NS record types.
+
+ If the flag is set to 1, the NS RR type bit for a delegation point
+ ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR
+ type bit MUST be ignored during processing of the NSEC3 RR. The NS
+ RR type bit has no meaning in this context (it is not authoritative),
+ hence the NSEC3 does not contest the existence of a NS RRset for this
+ ownername. When a delegation is not secured, there exist no DS RR
+ type nor any other authoritative types for this delegation, hence the
+ unsecured delegation has no NSEC3 record associated. Please see the
+ Special Consideration section for implications for unsigned
+ delegations.
+
+ If the flag is set to 0, the NS RR type bit for a delegation point
+ ownername MUST be set if the NSEC3 covers a delegation, even though
+ the NS RR itself is not authoritative. This implies that all
+ delegations, signed or unsigned, have an NSEC3 record associated.
+ This behaviour is identical to NSEC behaviour.
+
+2.1.2 The Hash Function Field
+
+ The Hash Function field identifies the cryptographic hash function
+ used to construct the hash-value.
+
+ This document defines Value 1 for SHA-1 and Value 127 for
+ experimental. All other values are reserved.
+
+ On reception, a resolver MUST discard an NSEC3 RR with an unknown
+ hash function value.
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 6]
+
+Internet-Draft nsec3 june 2005
+
+
+2.1.3 The Iterations Field
+
+ The Iterations field defines the number of times the hash has been
+ iterated. More iterations results in greater resiliency of the hash
+ value against dictionary attacks, but at a higher cost for both the
+ server and resolver.
+
+2.1.4 The Salt Length Field
+
+ The salt length field defines the length of the salt in octets.
+
+2.1.5 The Salt Field
+
+ The Salt field is not present when the Salt Length Field has a value
+ of 0.
+
+ The Salt field is prepended to the original ownername before hashing
+ in order to defend against precalculated dictionary attacks.
+
+ The salt is also prepended during iterations of the hash function.
+
+ Note that although it is theoretically possible to cover the entire
+ possible ownername space with different salt values, it is
+ computationally infeasible to do so, and so there MUST be at least
+ one salt which is the same for all NSEC3 records. This means that no
+ matter what name is asked for in a query, it is guaranteed to be
+ possible to find a covering NSEC3 record. Note that this does not
+ preclude the use of two different salts at the same time - indeed
+ this may well occur naturally, due to rolling the salt value
+ periodically.
+
+ The salt value SHOULD be changed from time to time - this is to
+ prevent the use of a precomputed dictionary to reduce the cost of
+ enumeration.
+
+2.1.6 The Next Hashed Ownername Field
+
+ The Next Hashed Ownername field contains the hash of the ownername of
+ the next RR in the canonical ordering of the hashed ownernames of the
+ zone. The value of the Next Hashed Ownername Field in the last NSEC3
+ record in the zone is the same as the ownername of the first NSEC3 RR
+ in the zone in canonical order.
+
+ Hashed ownernames of RRsets not authoritative for the given zone
+ (such as glue records) MUST NOT be listed in the Next Hashed
+ Ownername unless at least one authoritative RRset exists at the same
+ ownername.
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 7]
+
+Internet-Draft nsec3 june 2005
+
+
+ Note that the Next Hashed Ownername field is not encoded, unlike the
+ NSEC3 RR's ownername. It is the unmodified binary hash value.
+
+2.1.7 The list of Type Bit Map(s) Field
+
+ The Type Bit Maps field identifies the RRset types which exist at the
+ NSEC3 RR's ownername.
+
+ The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
+ generation, and MUST be ignored during processing.
+
+ 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 window block's
+ bitmap, and up to 32 octets (256 bits) of bitmap.
+
+ Blocks are present in the NSEC3 RR RDATA in increasing numerical
+ order.
+
+ "|" denotes concatenation
+
+ Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+ 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 NSEC3
+ RR's ownername. If a bit is set to 0, it indicates that no RRset of
+ that type is present for the NSEC3 RR's ownername.
+
+ The RR type 2 (NS) is authoritative at the apex of a zone and is not
+ authoritative at delegation points. If the Authoritative Only Flag
+ is set to 1, the delegation point NS RR type MUST NOT be included in
+ the type bit maps. If the Authoritative Only Flag is set to 0, the
+ NS RR type at a delegation point MUST be included in the type bit
+ maps.
+
+ 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 RFC 2929
+ [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
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 8]
+
+Internet-Draft nsec3 june 2005
+
+
+ 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 each block's
+ bitmap is determined by the type code with the largest numerical
+ value, within that block, among the set of RR types present at the
+ NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
+ be interpreted as zero octets.
+
+2.2 The NSEC3 RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Authoritative Only Field is represented as an unsigned decimal
+ integer. The value are either 0 or 1.
+
+ The Hash field is presented as the name of the hash or as an unsigned
+ decimal integer. The value has a maximum of 127.
+
+ The Iterations field is presented as an unsigned decimal integer.
+
+ The Salt Length field is not presented.
+
+ 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 00 when the Salt Length field has
+ value 0.
+
+ The Next Hashed Ownername field is represented as a sequence of case-
+ insensitive base32 digits. Whitespace is allowed within the
+ sequence.
+
+ The List of Type Bit Map(s) Field is represented as a sequence of RR
+ type mnemonics. When the mnemonic is not known, the TYPE
+ representation as described in RFC 3597 [RFC3597] (section 5) MUST be
+ used.
+
+3. Creating Additional NSEC3 RRs for Empty Non Terminals
+
+ In order to prove the non-existence of a record that might be covered
+ by a wildcard, it is necessary to prove the existence of its closest
+ encloser. A closest encloser might be an Empty Non Terminal.
+
+ Additional NSEC3 RRs are synthesized which cover every existing
+ intermediate label level. Additional NSEC3 RRs are identical in
+ format to NSEC3 RRs that cover existing RRs in the zone. The
+ difference is that the type-bit-maps only indicate the existence of
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 9]
+
+Internet-Draft nsec3 june 2005
+
+
+ an NSEC3 RR type and an RRSIG RR type.
+
+4. Calculation of the Hash
+
+ Define H(x) to be the hash of x using the hash function selected by
+ the NSEC3 record and || to indicate concatenation. Then define:
+
+ IH(salt,x,0)=H(x || salt)
+
+ IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
+
+ Then the calculated hash of an ownername is
+ IH(salt,ownername,iterations-1), where the ownername is the canonical
+ form.
+
+ The canonical form of the ownername is the wire format of the
+ ownername where:
+ 1. The ownername 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 ownername is a wildcard name, the ownername is in its
+ original unexpanded form, including the "*" label (no wildcard
+ substitution);
+
+5. Including NSEC3 RRs in a Zone
+
+ Each owner name in the zone which has authoritative data or a secured
+ delegation point NS RRset MUST have an NSEC3 resource record.
+
+ An unsecured delegation point NS RRset MAY have an NSEC3 resource
+ record. This is different from NSEC records where an unsecured
+ delegation point NS RRset MUST have an NSEC record.
+
+ The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
+ value field in the zone SOA RR.
+
+ The type bitmap of every NSEC3 resource record in a signed zone MUST
+ indicate the presence of both the NSEC3 RR type itself and its
+ corresponding RRSIG RR type.
+
+ The bitmap for the NSEC3 RR at a delegation point requires special
+ attention. Bits corresponding to the delegation NS RRset and any
+ RRsets for which the parent zone has authoritative data MUST be set;
+ bits corresponding to any non-NS RRset for which the parent is not
+ authoritative MUST be clear.
+
+ The following steps describe the proper construction of NSEC3
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 10]
+
+Internet-Draft nsec3 june 2005
+
+
+ records.
+ 1. For each unique original owner name in the zone, add an NSEC3
+ RRset. This includes NSEC3 RRsets for unsigned delegation point
+ NS RRsets, unless the policy is to have Authoritative Only NSEC3
+ RRsets. The ownername of the NSEC3 RR is the hashed equivalent
+ of the original owner name, prepended to the zone name.
+ 2. For each RRset at the original owner, set the corresponding bit
+ in the type bit map.
+ 3. If the difference in number of labels between the apex and the
+ original ownername is greater then 1, additional NSEC3s need to
+ be added for every empty non-terminal between the apex and the
+ original ownername.
+ 4. Sort the set of NSEC3 RRs.
+ 5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next
+ Hashed Ownername of the last NSEC3 in the zone contains the value
+ of the hashed ownername of the first NSEC3 in the zone.
+ 6. If the policy is to have authoritative only, set the
+ Authoritative Only bit in those NSEC3 RRs that cover unsecured
+ delegation points.
+
+6. Special Considerations
+
+ The following paragraphs clarify specific behaviour explain special
+ considerations for implementations.
+
+6.1 Delegation Points
+
+ This proposal introduces the Authoritative Only Flag which indicates
+ whether non authoritative delegation point NS records are included in
+ the type bit Maps. As discussed in paragraph 2.1.1, a flag value of
+ 0 indicates that the interpretation of the type bit maps is identical
+ to NSEC records.
+
+ The following subsections describe behaviour when the flag value is
+ 1.
+
+6.1.1 Unsigned Delegations
+
+ Delegation point NS records are not authoritative. They are
+ authoritative in the delegated zone. No other data exists at the
+ ownername of an unsigned delegation point.
+
+ Since no authoritative data exist at this ownername, it is excluded
+ from the NSEC3 chain. This is an optimization, since it relieves the
+ zone of including an NSEC3 record and its associated signature for
+ this name.
+
+ An NSEC3 that denies existence of ownernames between X and X' with
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 11]
+
+Internet-Draft nsec3 june 2005
+
+
+ the Authoritative Only Flag set to 1 can not be used to prove the
+ presence or the absence of delegation point NS records for unsigned
+ delegations in the interval (X, X'). The Authoritative Only Flag
+ effectively states No Contest on the presence of delegation point NS
+ resource records.
+
+ Since proof is absent, there exists a new attack vector. Unsigned
+ delegation point NS records can be deleted during a man in the middle
+ attack, effectively denying existence of the delegation. This is a
+ form of Denial of Service, where the victim has no information it is
+ under attack, since all signatures are valid and the fabricated
+ response form is a known type of response.
+
+ The only possible mitigation is to either not use this method, hence
+ proving existence or absence of unsigned delegations, or to sign all
+ delegations, regardless of whether the delegated zone is signed or
+ not.
+
+ A second attack vector exists in that an adversary is able to
+ successfully fabricate an (unsigned) response claiming a nonexistent
+ delegation exists.
+
+ The only possible mitigation is to mandate the signing of all
+ delegations.
+
+6.2 Proving Nonexistence
+
+ If a wildcard resource record appears in a zone, its asterisk label
+ is treated as a literal symbol and is treated in the same way as any
+ other ownername for purposes of generating NSEC3 RRs. RFC 4035
+ [RFC4035] describes the impact of wildcards on authenticated denial
+ of existence.
+
+ In order to prove there exist no RRs for a domain, as well as no
+ source of synthesis, an RR must be shown for the closest encloser,
+ and non-existence must be shown for all closer labels and for the
+ wildcard at the closest encloser.
+
+ This can be done as follows. If the QNAME in the query is
+ omega.alfa.beta.example, and the closest encloser is beta.example
+ (the nearest ancestor to omega.alfa.beta.example), then the server
+ should return an NSEC3 that demonstrates the nonexistence of
+ alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
+ *.beta.example, and an NSEC3 that demonstrates the existence of
+ beta.example. This takes between one and three NSEC3 records, since
+ a single record can, by chance, prove more than one of these facts.
+
+ When a verifier checks this response, then the existence of
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 12]
+
+Internet-Draft nsec3 june 2005
+
+
+ beta.example together with the non-existence of alfa.beta.example
+ proves that the closest encloser is indeed beta.example. The non-
+ existence of *.beta.example shows that there is no wildcard at the
+ closest encloser, and so no source of synthesis for
+ omega.alfa.beta.example. These two facts are sufficient to satisfy
+ the resolver that the QNAME cannot be resolved.
+
+ In practice, since the NSEC3 owner and next names are hashed, if the
+ server responds with an NSEC3 for beta.example, the resolver will
+ have to try successively longer names, starting with example, moving
+ to beta.example, alfa.beta.example, and so on, until one of them
+ hashes to a value that matches the interval (but not the ownername
+ nor next owner name) of one of the returned NSEC3s (this name will be
+ alfa.beta.example). Once it has done this, it knows the closest
+ encloser (i.e. beta.example), and can then easily check the other two
+ required proofs.
+
+ Note that it is not possible for one of the shorter names tried by
+ the resolver to be denied by one of the returned NSEC3s, since, by
+ definition, all these names exist and so cannot appear within the
+ range covered by an NSEC3. Note, however, that the first name that
+ the resolver tries MUST be the apex of the zone, since names above
+ the apex could be denied by one of the returned NSEC3s.
+
+6.3 Salting
+
+ Augmenting original ownernames with salt before hashing increases the
+ cost of a dictionary of pre-generated hash-values. For every bit of
+ salt, the cost of the dictionary doubles. The NSEC3 RR can use a
+ maximum of 2040 bits of salt, multiplying the cost by 2^2040.
+
+ There MUST be a complete set of NSEC3s for the zone using the same
+ salt value. The salt value for each NSEC3 RR MUST be equal for a
+ single version of the zone.
+
+ The salt SHOULD be changed every time the zone is resigned to prevent
+ precomputation using a single salt.
+
+6.4 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.
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 13]
+
+Internet-Draft nsec3 june 2005
+
+
+6.4.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
+ SHOULD be chosen and all hash values SHOULD be regenerated.
+
+ If hash values are not regenerated on collision, the NSEC3 RR MUST
+ list all authoritative RR types that exist for both owners, to avoid
+ a replay attack, spoofing an existing type as non-existent.
+
+6.4.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.
+
+6.4.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 ownernames 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 resistance is 2^n.
+
+ An extreme hash value truncation would be truncating to the shortest
+ possible unique label value. Considering that hash values are
+ presented in base32, which represents 5 bits per label character,
+ truncation must be done on a 5 bit boundary. This would be unwise,
+ since the work factor to produce collisions would then approximate
+ the size of the zone.
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 14]
+
+Internet-Draft nsec3 june 2005
+
+
+ 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 signalled simply by reducing the length of the
+ first label in the ownername. Note that there would have to be a
+ corresponding reduction in the length of the Next Hashed Ownername
+ field.
+
+7. Performance Considerations
+
+ Iterated hashes will obviously impose a performance penalty on both
+ authoritative servers and resolvers. Therefore, the number of
+ iterations should be carefully chosen. In particular it should be
+ noted that a high value for iterations gives an attacker a very good
+ denial of service attack, since the attacker need not bother to
+ verify the results of their queries, and hence has no performance
+ penalty of his own.
+
+ On the other hand, nameservers with low query rates and limited
+ bandwidth are already subject to a bandwidth based denial of service
+ attack, since responses are typically an order of magnitude larger
+ than queries, and hence these servers may choose a high value of
+ iterations in order to increase the difficulty of offline attempts to
+ enumerate their namespace without significantly increasing their
+ vulnerability to denial of service attacks.
+
+8. IANA Considerations
+
+ IANA has to create a new registry for NSEC3 Hash Functions. The
+ range for this registry is 0-127. Value 0 is the identity function.
+ Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value
+ 127 is marked as Experimental.
+
+9. Security Considerations
+
+ The NSEC3 records are still susceptible to dictionary attacks (i.e.
+ the attacker retrieves all the NSEC3 records, then calculates the
+ hashes of all likely domain names, comparing against the hashes found
+ in the NSEC3 records, and thus enumerating the zone). These are
+ substantially more expensive than traversing the original NSEC
+ records 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.
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 15]
+
+Internet-Draft nsec3 june 2005
+
+
+ The expense of this off-line attack can be chosen by setting the
+ number of iterations in the NSEC3 RR.
+
+ High-value domains are also susceptible to a precalculated dictionary
+ attack - that is, a list of hashes for all likely names is computed
+ once, then NSEC3 is scanned periodically and compared against the
+ precomputed hashes. This attack is prevented by changing the salt on
+ a regular basis.
+
+ Walking the NSEC3 RRs will reveal the total number of records in the
+ zone, and also what types they are. This could be mitigated by
+ adding dummy entries, but certainly an upper limit can always be
+ found.
+
+ Hash collisions may occur. If they do, it will be impossible to
+ prove the non-existence of the colliding domain - however, this is
+ fantastically unlikely, and, in any case, DNSSEC already relies on
+ SHA-1 to not collide.
+
+10. References
+
+10.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.
+
+ [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.
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 16]
+
+Internet-Draft nsec3 june 2005
+
+
+ [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
+ Extensions", RFC 4035, March 2005.
+
+10.2 Informative References
+
+ [I-D.ietf-dnsext-trustupdate-threshold]
+ Ihren, J., "An In-Band Rollover Mechanism and an Out-Of-
+ Band Priming Method for DNSSEC Trust Anchors.",
+ draft-ietf-dnsext-trustupdate-threshold-00 (work in
+ progress), October 2004.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2418] Bradner, S., "IETF Working Group Guidelines and
+ Procedures", BCP 25, RFC 2418, September 1998.
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 17]
+
+Internet-Draft nsec3 june 2005
+
+
+ Roy Arends
+ Telematica Instituut
+ Brouwerijstraat 1
+ 7523 XC Enschede
+ The Netherlands
+
+ Phone: +31 (53) 485 0485
+ Email: roy.arends@telin.nl
+
+Appendix A. Example Zone
+
+ This is a zone showing its NSEC3 records. They can also be used as
+ test vectors for the hash algorithm.
+
+
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600 )
+ 3600 RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ 3600 NS ns1.example.
+ 3600 NS ns2.example.
+ 3600 RRSIG NS 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+ m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+ 1SH5r/wfjuCg+g== )
+ 3600 MX 1 xx.example.
+ 3600 RRSIG MX 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
+ NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
+ S/o/g5C8VM6ftQ== )
+ 3600 DNSKEY 257 3 5 (
+ AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
+ cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
+ zsYKWJ7BvR2894hX
+ ) ; Key ID = 21960
+ 3600 DNSKEY 256 3 5 (
+ AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
+ 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
+ ExXT48OGGdbfIme5
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 18]
+
+Internet-Draft nsec3 june 2005
+
+
+ ) ; Key ID = 62699
+ 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
+ xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
+ mTkunTYzqWJrmQ== )
+ 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
+ 20050612112304 21960 example.
+ SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
+ ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
+ 3w7ZY2UWyYIvpw== )
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2
+ NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
+ Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
+ sb7KfbaUo/vzAg== )
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+ MX NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+ ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+ MEFQmc/gEuxojA== )
+ a.example. 3600 IN NS ns1.a.example.
+ 3600 IN NS ns2.a.example.
+ 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
+ 766A6A4837206C )
+ 3600 RRSIG DS 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+ cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+ 0kx7rGKTc3RQDA== )
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+ ai.example. 3600 IN A 192.0.2.9
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+ 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+ ZXW5S+1VjMZYzQ== )
+ 3600 HINFO "KLH-10" "ITS"
+ 3600 RRSIG HINFO 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 19]
+
+Internet-Draft nsec3 june 2005
+
+
+ 20050612112304 62699 example.
+ AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
+ tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
+ VGNmbgPnqDVPiA== )
+ 3600 AAAA 2001:db8:0:0:0:0:f00:baa9
+ 3600 RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+ ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+ l5/UqLCJJ9BDMg== )
+ b.example. 3600 IN NS ns1.b.example.
+ 3600 IN NS ns2.b.example.
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ gmnfcccja7wkax3iv26bs75myptje3qk
+ MX DNSKEY NS SOA NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+ C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+ MOiKMSHozVebqw== )
+ gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
+ DS NS NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
+ ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
+ OwQBGbOegrW/Zw== )
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ kcll7fqfnisuhfekckeeqnmbbd4maanu
+ NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+ IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+ 94Zbq3k8lgdpZA== )
+ kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
+ deadbeaf
+ n42hbhnjj333xdxeybycax5ufvntux5d
+ MX NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 20]
+
+Internet-Draft nsec3 june 2005
+
+
+ IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+ TOLtc5jPrkL4zQ== )
+ n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu
+ A NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
+ 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
+ xFPFGRIW3wKnrA== )
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ vhgwr2qgykdkf4m6iv6vkagbxozphazr
+ HINFO A AAAA NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+ z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+ jL33Wm1p07TBdw== )
+ ns1.example. 3600 A 192.0.2.1
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+ BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+ nWWLepz1PjjShQ== )
+ ns2.example. 3600 A 192.0.2.2
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+ P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+ AkeTJu3J3auUiA== )
+ vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw
+ HINFO A AAAA NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
+ kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
+ 5SNSHIyfpfsi6A== )
+ *.w.example. 3600 MX 1 ai.example.
+ 3600 RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+ xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+ gQlgxEwhvQDEaQ== )
+ x.w.example. 3600 MX 1 xx.example.
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 21]
+
+Internet-Draft nsec3 june 2005
+
+
+ 3600 RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+ lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+ U9VazOa1KEIq1w== )
+ x.y.w.example. 3600 MX 1 xx.example.
+ 3600 RRSIG MX 5 4 3600 20050712112304 (
+ 20050612112304 62699 example.
+ aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
+ uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
+ 9VrQvJjwbllAfA== )
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+ A NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+ ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+ oorBv4xkb0flXw== )
+ xx.example. 3600 A 192.0.2.10
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+ tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+ cxwCXWj82GVGdw== )
+ 3600 HINFO "KLH-10" "TOPS-20"
+ 3600 RRSIG HINFO 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
+ OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
+ KMf4DgNBDj+dIQ== )
+ 3600 AAAA 2001:db8:0:0:0:0:f00:baaa
+ 3600 RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+ w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+ rzKKwb8J04/ILw== )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+ MX NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+ 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+ OcFlrPGPMm48/A== )
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 22]
+
+Internet-Draft nsec3 june 2005
+
+
+Appendix B. Example Responses
+
+ The examples in this section show response messages using the signed
+ zone example in Appendix A.
+
+B.1 answer
+
+ A successful query to an authoritative server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 23]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ x.w.example. IN MX
+
+ ;; Answer
+ x.w.example. 3600 IN MX 1 xx.example.
+ x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+ lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+ U9VazOa1KEIq1w== )
+
+ ;; Authority
+ example. 3600 IN NS ns1.example.
+ example. 3600 IN NS ns2.example.
+ example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+ m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+ 1SH5r/wfjuCg+g== )
+
+ ;; Additional
+ xx.example. 3600 IN A 192.0.2.10
+ xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+ tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+ cxwCXWj82GVGdw== )
+ xx.example. 3600 IN AAAA 2001:db8::f00:baaa
+ xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+ w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+ rzKKwb8J04/ILw== )
+ ns1.example. 3600 IN A 192.0.2.1
+ ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+ BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+ nWWLepz1PjjShQ== )
+ ns2.example. 3600 IN A 192.0.2.2
+ ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+ P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+ AkeTJu3J3auUiA== )
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 24]
+
+Internet-Draft nsec3 june 2005
+
+
+ The query returned an MX RRset for "x.w.example". The corresponding
+ RRSIG RR indicates that the MX RRset was signed by an "example"
+ DNSKEY with algorithm 5 and key tag 62699. The resolver needs the
+ corresponding DNSKEY RR in order to authenticate this answer. The
+ discussion below describes how a resolver might obtain this DNSKEY
+ RR.
+
+ The RRSIG RR indicates the original TTL of the MX RRset was 3600,
+ and, for the purpose of authentication, the current TTL is replaced
+ by 3600. The RRSIG RR's labels field value of 3 indicates that the
+ answer was not the result of wildcard expansion. The "x.w.example"
+ MX RRset is placed in canonical form, and, assuming the current time
+ falls between the signature inception and expiration dates, the
+ signature is authenticated.
+
+B.1.1 Authenticating the Example DNSKEY RRset
+
+ This example shows the logical authentication process that starts
+ from a configured root DNSKEY RRset (or DS RRset) and moves down the
+ tree to authenticate the desired "example" DNSKEY RRset. Note that
+ the logical order is presented for clarity. An implementation may
+ choose to construct the authentication as referrals are received or
+ to construct the authentication chain only after all RRsets have been
+ obtained, or in any other combination it sees fit. The example here
+ demonstrates only the logical process and does not dictate any
+ implementation rules.
+
+ We assume the resolver starts with a configured DNSKEY RRset for the
+ root zone (or a configured DS RRset for the root zone). The resolver
+ checks whether this configured DNSKEY RRset is present in the root
+ DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
+ RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
+ root DNSKEY RRset, and whether the signature lifetime is valid. If
+ all these conditions are met, all keys in the DNSKEY RRset are
+ considered authenticated. The resolver then uses one (or more) of
+ the root DNSKEY RRs to authenticate the "example" DS RRset. Note
+ that the resolver may have to query the root zone to obtain the root
+ DNSKEY RRset or "example" DS RRset.
+
+ Once the DS RRset has been authenticated using the root DNSKEY, the
+ resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+ RR that matches one of the authenticated "example" DS RRs. If such a
+ matching "example" DNSKEY is found, the resolver checks whether this
+ DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+ lifetime is valid. If these conditions are met, all keys in the
+ "example" DNSKEY RRset are considered authenticated.
+
+ Finally, the resolver checks that some DNSKEY RR in the "example"
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 25]
+
+Internet-Draft nsec3 june 2005
+
+
+ DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
+ DNSKEY is used to authenticate the RRSIG included in the response.
+ If multiple "example" DNSKEY RRs match this algorithm and key tag,
+ then each DNSKEY RR is tried, and the answer is authenticated if any
+ of the matching DNSKEY RRs validate the signature as described above.
+
+B.2 Name Error
+
+ An authoritative name error. The NSEC3 RRs prove that the name does
+ not exist and that no covering wildcard exists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 26]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=3
+ ;;
+ ;; Question
+ a.c.x.w.example. IN A
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+ MX NSEC3 RRSIG )
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+ ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+ MEFQmc/gEuxojA== )
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ vhgwr2qgykdkf4m6iv6vkagbxozphazr
+ HINFO A AAAA NSEC3 RRSIG )
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+ z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+ jL33Wm1p07TBdw== )
+ ;; Additional
+ ;; (empty)
+
+ The query returned two NSEC3 RRs that prove that the requested data
+ does not exist and no wildcard applies. The negative reply is
+ authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are
+ authenticated in a manner identical to that of the MX RRset discussed
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 27]
+
+Internet-Draft nsec3 june 2005
+
+
+ above. At least one of the owner names of the NSEC3 RRs will match
+ the closest encloser. At least one of the NSEC3 RRs prove that there
+ exists no longer name. At least one of the NSEC3 RRs prove that
+ there exists no wildcard RRsets that should have been expanded. The
+ closest encloser can be found by hasing the apex ownername (The SOA
+ RR's ownername, or the ownername of the DNSKEY RRset referred by an
+ RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
+ if that fails, continue by adding labels.
+
+ In the above example, the name 'x.w.example' hashes to
+ '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might
+ be the closest encloser. To prove that 'c.x.w.example' and
+ '*.x.w.example' do not exists, these names are hashed to respectively
+ 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
+ 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that
+ these hashed ownernames do not exists, since the names are within the
+ given intervals.
+
+B.3 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 December 3, 2005 [Page 28]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ ns1.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+ A NSEC3 RRSIG )
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+ ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+ oorBv4xkb0flXw== )
+ ;; Additional
+ ;; (empty)
+
+ The query returned an NSEC3 RR that proves that the requested name
+ exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
+ but the requested RR type does not exist (type MX is absent in the
+ type code list of the NSEC RR). The negative reply is authenticated
+ by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
+ identical to that of the MX RRset discussed above.
+
+B.3.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 December 3, 2005 [Page 29]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ y.w.example. IN A
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ kcll7fqfnisuhfekckeeqnmbbd4maanu
+ NSEC3 RRSIG )
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+ IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+ 94Zbq3k8lgdpZA== )
+
+ The query returned an NSEC3 RR that proves that the requested name
+ exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
+ but the requested RR type does not exist (Type A is absent in the
+ type-bit-maps of the NSEC3 RR). The negative reply is authenticated
+ by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
+ identical to that of the MX RRset discussed above. Note that, unlike
+ generic empty non terminal proof using NSECs, this is identical to
+ proving a No Data Error. This example is solely mentioned to be
+ complete.
+
+B.4 Referral to Signed Zone
+
+ Referral to a signed zone. The DS RR contains the data which the
+ resolver will need to validate the corresponding DNSKEY RR in the
+ child zone's apex.
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 30]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+
+ ;; Question
+ mc.a.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ a.example. 3600 IN NS ns1.a.example.
+ a.example. 3600 IN NS ns2.a.example.
+ a.example. 3600 IN DS 58470 5 1 (
+ 3079F1593EBAD6DC121E202A8B766A6A4837
+ 206C )
+ a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+ cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+ 0kx7rGKTc3RQDA== )
+
+ ;; Additional
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+
+ The query returned a referral to the signed "a.example." zone. The
+ DS RR is authenticated in a manner identical to that of the MX RRset
+ discussed above. This DS RR is used to authenticate the "a.example"
+ DNSKEY RRset.
+
+ Once the "a.example" DS RRset has been authenticated using the
+ "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+ for some "a.example" DNSKEY RR that matches the DS RR. If such a
+ matching "a.example" DNSKEY is found, the resolver checks whether
+ this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+ the signature lifetime is valid. If all these conditions are met,
+ all keys in the "a.example" DNSKEY RRset are considered
+ authenticated.
+
+B.5 Referral to Unsigned Zone using Opt-In
+
+ Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that
+ nothing for this delegation was signed in the parent zone. There is
+ no proof that the delegation exists
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 31]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+ ;; Question
+ mc.b.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ b.example. 3600 IN NS ns1.b.example.
+ b.example. 3600 IN NS ns2.b.example.
+ kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
+ deadbeaf
+ n42hbhnjj333xdxeybycax5ufvntux5d
+ MX NSEC3 RRSIG )
+ kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+ IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+ TOLtc5jPrkL4zQ== )
+
+ ;; Additional
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+
+ The query returned a referral to the unsigned "b.example." zone. The
+ NSEC3 proves that no authentication leads from "example" to
+ "b.example", since the hash of "b.example"
+ ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
+ the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a
+ manner identical to that of the MX RRset discussed above.
+
+B.6 Wildcard Expansion
+
+ A successful query that was answered via wildcard expansion. The
+ label count in the answer's RRSIG RR indicates that a wildcard RRset
+ was expanded to produce this response, and the NSEC3 RR proves that
+ no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 32]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN MX
+
+ ;; Answer
+ a.z.w.example. 3600 IN MX 1 ai.example.
+ a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+ xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+ gQlgxEwhvQDEaQ== )
+ ;; Authority
+ example. 3600 NS ns1.example.
+ example. 3600 NS ns2.example.
+ example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+ m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+ 1SH5r/wfjuCg+g== )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+ MX NSEC3 RRSIG )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+ 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+ OcFlrPGPMm48/A== )
+ ;; Additional
+ ai.example. 3600 IN A 192.0.2.9
+ ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+ 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+ ZXW5S+1VjMZYzQ== )
+ ai.example. 3600 AAAA 2001:db8::f00:baa9
+ ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+ ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+ l5/UqLCJJ9BDMg== )
+
+ 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, and the
+ corresponding RRSIG indicates that the expanded wildcard MX RRset was
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 33]
+
+Internet-Draft nsec3 june 2005
+
+
+ signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
+ The RRSIG indicates that the original TTL of the MX RRset was 3600,
+ and, for the purpose of authentication, the current TTL is replaced
+ by 3600. 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. The name "a.z.w.example" is replaced by
+ "*.w.example", the MX RRset is placed in canonical form, and,
+ assuming that the current time falls between the signature inception
+ and expiration dates, the signature is authenticated.
+
+ The NSEC3 proves that no closer match (exact or closer wildcard)
+ could have been used to answer this query, and the NSEC3 RR must also
+ be authenticated before the answer is considered valid.
+
+B.7 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 34]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN AAAA
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+ MX NSEC3 RRSIG )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+ 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+ OcFlrPGPMm48/A== )
+ ;; Additional
+ ;; (empty)
+
+ The query returned NSEC3 RRs that prove that the requested data does
+ not exist and no wildcard applies. The negative reply is
+ authenticated by verifying both NSEC3 RRs.
+
+B.8 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 December 3, 2005 [Page 35]
+
+Internet-Draft nsec3 june 2005
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ example. IN DS
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ gmnfcccja7wkax3iv26bs75myptje3qk
+ MX DNSKEY NS SOA NSEC3 RRSIG )
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+ C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+ MOiKMSHozVebqw== )
+
+ ;; Additional
+ ;; (empty)
+
+ The query returned NSEC RRs that shows the requested was answered by
+ a child server ("example" server). The NSEC RR indicates the
+ presence of an SOA RR, showing that the answer is from the child .
+ Queries for the "example" DS RRset should be sent to the parent
+ servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 36]
+
+Internet-Draft nsec3 june 2005
+
+
+Intellectual Property Statement
+
+ 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.
+
+
+Disclaimer of Validity
+
+ 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 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.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005). 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Laurie, et al. Expires December 3, 2005 [Page 37]
+
OpenPOWER on IntegriCloud