diff options
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.txt | 2072 |
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] + |