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, 0 insertions, 2072 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 deleted file mode 100644 index cc3c276..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-02.txt +++ /dev/null @@ -1,2072 +0,0 @@ - - - -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] - |
