Network Working Group B. Laurie
Internet-Draft G. Sisson
Expires: August 5, 2006 R. Arends
Nominet
February 2006
DNSSEC Hash Authenticated Denial of Existence
draft-ietf-dnsext-nsec3-04
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 August 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The DNS Security Extensions introduces the NSEC resource record for
authenticated denial of existence. This document introduces a new
resource record as an alternative to NSEC that provides measures
against zone enumeration and allows for gradual expansion of
delegation-centric zones.
Laurie, et al. Expires August 5, 2006 [Page 1]
Internet-Draft nsec3 February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5
3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6
3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6
3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7
3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8
3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8
3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8
3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9
3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9
3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11
5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11
6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11
7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12
8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13
8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
8.4.1. Avoiding Hash Collisions during generation . . . . . . 16
8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16
8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17
8.4.4. Server Response to a Run-time Collision . . . . . . . 17
8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18
9. Performance Considerations . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 27
B.1. answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.1.1. Authenticating the Example DNSKEY RRset . . . . . . . 29
B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . . 32
B.3.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 33
B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . . 34
B.5. Referral to Unsigned Zone using the Opt-In Flag . . . . . 35
B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
Laurie, et al. Expires August 5, 2006 [Page 2]
Internet-Draft nsec3 February 2006
B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 42
Laurie, et al. Expires August 5, 2006 [Page 3]
Internet-Draft nsec3 February 2006
1. Introduction
1.1. Rationale
The DNS Security Extensions included the NSEC RR to provide
authenticated denial of existence. Though the NSEC RR meets the
requirements for authenticated denial of existence, it introduced a
side-effect in that the contents of a zone can be enumerated. This
property introduces undesired policy issues.
An enumerated zone can be used either directly as a source of
probable e-mail addresses for spam, or indirectly as a key for
multiple WHOIS queries to reveal registrant data which many
registries may be under strict legal obligations to protect. Many
registries therefore prohibit copying of their zone file; however the
use of NSEC RRs renders these policies unenforceable.
A second problem was the requirement that the existence of all record
types in a zone - including unsigned delegation points - must be
accounted for, despite the fact that unsigned delegation point
records are not signed. This requirement has a side-effect that the
overhead of signed zones is not related to the increase in security
of subzones. This requirement does not allow the zones' size to grow
in relation to the growth of signed subzones.
In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) 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) [14] 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 and DNSSEC
concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
[6], RFC2181 [7] and RFC2308 [8].
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 [9].
1.3. Terminology
The practice of discovering the contents of a zone, i.e. enumerating
the domains within a zone, is known as "zone enumeration". Zone
Laurie, et al. Expires August 5, 2006 [Page 4]
Internet-Draft nsec3 February 2006
enumeration was not practical prior to the introduction of DNSSEC.
In this document the term "original ownername" refers to a standard
ownername. Because this proposal uses the result of a hash function
over the original (unmodified) ownername, this result is referred to
as "hashed ownername".
"Hash order" means the order in which hashed ownernames are arranged
according to their numerical value, treating the leftmost (lowest
numbered) octet as the most significant octet. Note that this is the
same as the canonical ordering specified in RFC 4034 [4].
An "empty non-terminal" is a domain name that owns no resource
records but has subdomains that do.
The "closest encloser" of a (nonexistent) domain name is the longest
domain name, including empty non-terminals, that matches the
rightmost part of the nonexistent domain name.
"Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
specified in RFC 3548bis [15].
2. NSEC versus NSEC3
This document does NOT obsolete the NSEC record, but gives an
alternative for authenticated denial of existence. NSEC and NSEC3
RRs can not co-exist in a zone. See draft-vixie-dnssec-ter [14] for
a signaling mechanism to allow for graceful transition towards NSEC3.
3. The NSEC3 Resource Record
The NSEC3 RR provides Authenticated Denial of Existence for DNS
Resource Record Sets.
The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
RR's original ownername. It includes the next hashed ownername in
the hash order 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 [5]. To provide protection against zone
enumeration, 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 hashing
Laurie, et al. Expires August 5, 2006 [Page 5]
Internet-Draft nsec3 February 2006
technique is described fully in Section 5.
Hashed ownernames of unsigned delegations may be excluded from the
chain. An NSEC3 record which span covers the hash of an unsigned
delegation's ownername is referred to as an Opt-In NSEC3 record and
is indicated by the presence of a flag.
The ownername for the NSEC3 RR is the base32 encoding of the hashed
ownername prepended to the name of the zone..
The type value for the NSEC3 RR is XX.
The NSEC3 RR RDATA format is class independent and is described
below.
The class MUST be the same as the original ownername's class.
The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
field. This is in the spirit of negative caching [8].
3.1. NSEC3 RDATA Wire Format
The RDATA of the NSEC3 RR is as shown below:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash Function |O| Iterations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt Length | Salt /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Next Hashed Ownername /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"O" is the Opt-In Flag field.
3.1.1. The Hash Function Field
The Hash Function field identifies the cryptographic hash function
used to construct the hash-value.
The values are as defined for the DS record (see RFC 3658 [10]).
On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
function value.
Laurie, et al. Expires August 5, 2006 [Page 6]
Internet-Draft nsec3 February 2006
3.1.2. The Opt-In Flag Field
The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
delegations.
In DNSSEC, NS RRsets at delegation points are not signed, and may be
accompanied by a DS record. The security status of the subzone is
determined by the presence or absence of the DS RRset,
cryptographically proven by the NSEC record or the signed DS RRset.
The presence of the Opt-In flag expands this definition by allowing
insecure delegations to exist within an otherwise signed zone without
the corresponding NSEC3 record at the delegation's (hashed) owner
name. These delegations are proven insecure by using a covering
NSEC3 record.
Resolvers must be able to distinguish between NSEC3 records and
Opt-In NSEC3 records. This is accomplished by setting the Opt-In
flag of the NSEC3 records that cover (or potentially cover) insecure
delegation nodes.
An Opt-In NSEC3 record does not assert the existence or non-existence
of the insecure delegations that it covers. This allows for the
addition or removal of these delegations without recalculating or
resigning records in the NSEC3 chain. However, Opt-In NSEC3 records
do assert the (non)existence of other, authoritative RRsets.
An Opt-In NSEC3 record MAY have the same original owner name as an
insecure delegation. In this case, the delegation is proven insecure
by the lack of a DS bit in type map and the signed NSEC3 record does
assert the existence of the delegation.
Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
non-Opt-In NSEC3 records. If an NSEC3 record is not Opt-In, there
MUST NOT be any hashed ownernames of insecure delegations (nor any
other records) between it and the RRsets indicated by the 'Next
Hashed Ownername' in the NSEC3 RDATA. If it is Opt-In, there MUST
only be hashed ownernames of insecure delegations between it and the
next node indicated by the 'Next Hashed Ownername' in the NSEC3
RDATA.
In summary,
o An Opt-In NSEC3 type is identified by an Opt-In Flag field value
of 1.
o A non Opt-In NSEC3 type is identified by an Opt-In Flag field
value of 0.
and,
Laurie, et al. Expires August 5, 2006 [Page 7]
Internet-Draft nsec3 February 2006
o An Opt-In NSEC3 record does not assert the non-existence of a hash
ownername between its ownername and next hashed ownername,
although it does assert that any hashed name in this span MUST be
of an insecure delegation.
o An Opt-In NSEC3 record does assert the (non)existence of RRsets
with the same hashed owner name.
3.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. See Section 5 for details of this field's use.
Iterations make an attack more costly by making the hash computation
more computationally intensive, e.g. by iterating the hash function a
number of times.
When generating a few hashes this performance loss will not be a
problem, as a validator can handle a delay of a few milliseconds.
But when doing a dictionary attack it will also multiply the attack
workload by a factor, which is a problem for the attacker.
3.1.4. The Salt Length Field
The salt length field defines the length of the salt in octets.
3.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 appended to the original ownername before hashing
in order to defend against precalculated dictionary attacks. See
Section 5 for details on how the salt is used.
Salt is used to make dictionary attacks using precomputation more
costly. A dictionary can only be computed after the attacker has the
salt, hence a new salt means that the dictionary has to be
regenerated with the new salt.
There MUST be a complete set of NSEC3 records covering the entire
zone that use the same salt value. The requirement exists so that,
given any qname within a zone, at least one covering NSEC3 RRset may
be found. While it may be theoretically possible to produce a set of
NSEC3s that use different salts that cover the entire zone, it is
computationally infeasible to generate such a set. See Section 8.2
for further discussion.
Laurie, et al. Expires August 5, 2006 [Page 8]
Internet-Draft nsec3 February 2006
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.
3.1.6. The Next Hashed Ownername Field
The Next Hashed Ownername field contains the next hashed ownername in
hash order. That is, given the set of all hashed owernames, the Next
Hashed Ownername contains the hash value that immediately follows the
owner hash value for the given NSEC3 record. 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 hash
order.
Hashed ownernames of glue RRsets MUST NOT be listed in the Next
Hashed Ownername unless at least one authoritative RRset exists at
the same ownername. Hashed ownernames of delegation NS RRsets MUST
be listed if the Opt-In bit is clear.
Note that the Next Hashed Ownername field is not encoded, unlike the
NSEC3 RR's ownername. It is the unmodified binary hash value. It
does not include the name of the containing zone.
The length of this field is the length of the hash value produced by
the hash function selected by the Hash Function field.
3.1.7. The Type Bit Maps Field
The Type Bit Maps field identifies the RRset types which exist at the
NSEC3 RR's original 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 ) +
Laurie, et al. Expires August 5, 2006 [Page 9]
Internet-Draft nsec3 February 2006
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.
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 [11]
(section 3.1) or within the range reserved for assignment only to
QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
zone data. If encountered, they must be ignored upon reading.
Blocks with no types present MUST NOT be included. Trailing zero
octets in the bitmap MUST be omitted. The length of 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.
3.2. The NSEC3 RR Presentation Format
The presentation format of the RDATA portion is as follows:
The Opt-In Flag Field is represented as an unsigned decimal integer.
The value is either 0 or 1.
The Hash field is presented as a mnemonic 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 "-" (without the quotes) when the
Salt Length field has value 0.
The Next Hashed Ownername field is represented as a sequence of case-
insensitive base32 digits, without whitespace.
The Type Bit Maps Field is represented as a sequence of RR type
Laurie, et al. Expires August 5, 2006 [Page 10]
Internet-Draft nsec3 February 2006
mnemonics. When the mnemonic is not known, the TYPE representation
as described in RFC 3597 [12] (section 5) MUST be used.
4. 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 generated for empty non-terminals. These
additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
existing RRs in the zone except that their type-maps only indicated
the existence of an NSEC3 RRset and an RRSIG RRset.
This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
not appear at names that did not exist before the zone was signed.
[Comment.1]
5. 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);
This form is as defined in section 6.2 of RFC 4034 ([4]).
6. Including NSEC3 RRs in a Zone
Each ownername within the zone that owns authoritative RRsets MUST
Laurie, et al. Expires August 5, 2006 [Page 11]
Internet-Draft nsec3 February 2006
have a corresponding NSEC3 RR. Ownernames that correspond to
unsigned delegations MAY have a corresponding NSEC3 RR, however, if
there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
set to 1. Other non-authoritative RRs are not included in the set of
NSEC3 RRs.
Each empty non-terminal MUST have an NSEC3 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 following steps describe the proper construction of NSEC3
records. [Comment.2]
1. For each unique original ownername in the zone, add an NSEC3
RRset. If Opt-In is being used, ownernames of unsigned
delegations may be excluded, but must be considered for empty-
non-terminals. The ownername of the NSEC3 RR is the hashed
equivalent of the original owner name, prepended to the zone
name. The Next Hashed Ownername field is left blank for the
moment. If Opt-In is being used, set the Opt-In bit to one.
2. For each RRset at the original owner name, 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. This process may generate NSEC3 RRs with
duplicate hashed ownernames.
4. Sort the set of NSEC3 RRs into hash order. Hash order is the
ascending numerical order of the non-encoded hash values.
5. Combine NSEC3 RRs with identical hashed ownernames by replacing
with a single NSEC3 RR with the type map consisting of the union
of the types represented by the set of NSEC3 RRs.
6. In each NSEC3 RR, insert the Next Hashed Ownername by using the
value of the next NSEC3 RR in hash order. The Next Hashed
Ownername of the last NSEC3 in the zone contains the value of the
hashed ownername of the first NSEC3 in the hash order.
7. Responding to NSEC3 Queries
Since NSEC3 ownernames are not represented in the NSEC3 chain like
other zone ownernames, direct queries for NSEC3 ownernames present a
special case.
Laurie, et al. Expires August 5, 2006 [Page 12]
Internet-Draft nsec3 February 2006
The special case arises when the following are all true:
o The QNAME equals an existing NSEC3 ownername, and
o There are no other record types that exist at QNAME, and
o The QTYPE does not equal NSEC3.
These conditions describe a particular case: the answer should be a
NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
include in the authority section.
However, the NSEC3 RRset with ownername equal to QNAME is able to
prove its own existence. Thus, when answering this query, the
authoritative server MUST include the NSEC3 RRset whose ownername
equals QNAME. This RRset proves that QNAME is an existing name with
types NSEC3 and RRSIG. The authoritative server MUST also include
the NSEC3 RRset that covers the hash of QNAME. This RRset proves
that no other types exist.
When validating a NOERROR/NODATA response, validators MUST check for
a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
(validated) NSEC3 RRset as proof that QNAME exists. The validator
MUST also check for an NSEC3 RRset that covers the hash of QNAME as
proof that QTYPE doesn't exist.
Other cases where the QNAME equals an existing NSEC3 ownername may be
answered normally.
8. Special Considerations
The following paragraphs clarify specific behaviour explain special
considerations for implementations.
8.1. 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 [5]
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
Laurie, et al. Expires August 5, 2006 [Page 13]
Internet-Draft nsec3 February 2006
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
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.
8.2. 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 a precomputed dictionary doubles (because there
must be an entry for each word combined with each possible salt
value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
salt, multiplying the cost by 2^2040. This means that an attacker
must, in practice, recompute the dictionary each time the salt is
changed.
There MUST be at least one complete set of NSEC3s for the zone using
the same salt value.
The salt SHOULD be changed periodically to prevent precomputation
using a single salt. It is RECOMMENDED that the salt be changed for
every resigning.
Laurie, et al. Expires August 5, 2006 [Page 14]
Internet-Draft nsec3 February 2006
Note that this could cause a resolver to see records with different
salt values for the same zone. This is harmless, since each record
stands alone (that is, it denies the set of ownernames whose hashes,
using the salt in the NSEC3 record, fall between the two hashes in
the NSEC3 record) - it is only the server that needs a complete set
of NSEC3 records with the same salt in order to be able to answer
every possible query.
There is no prohibition with having NSEC3 with different salts within
the same zone. However, in order for authoritative servers to be
able to consistently find covering NSEC3 RRs, the authoritative
server MUST choose a single set of parameters (algorithm, salt, and
iterations) to use when selecting NSEC3s. In the absence of any
other metadata, the server does this by using the parameters from the
zone apex NSEC3, recognizable by the presence of the SOA bit in the
type map. If there is more than one NSEC3 record that meets this
description, then the server may arbitrarily choose one. Because of
this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
of a complete NSEC3 set. Conversely, if there exists an incomplete
set of NSEC3 RRs using the same parameters within a zone, there MUST
NOT be an NSEC3 RR using those parameters with the SOA bit set.
8.3. Iterations
Setting the number of iterations used allows the zone owner to choose
the cost of computing a hash, and so the cost of generating a
dictionary. Note that this is distinct from the effect of salt,
which prevents the use of a single precomputed dictionary for all
time.
Obviously the number of iterations also affects the zone owner's cost
of signing the zone as well as the verifiers cost of verifying the
zone. We therefore impose an upper limit on the number of
iterations. We base this on the number of iterations that
approximately doubles the cost of signing the zone.
A zone owner MUST NOT use a value higher than shown in the table
below for iterations. A resolver MAY treat a response with a higher
value as bogus.
+--------------+------------+
| RSA Key Size | Iterations |
+--------------+------------+
| 1024 | 3,000 |
| 2048 | 20,000 |
| 4096 | 150,000 |
+--------------+------------+
Laurie, et al. Expires August 5, 2006 [Page 15]
Internet-Draft nsec3 February 2006
+--------------+------------+
| DSA Key Size | Iterations |
+--------------+------------+
| 1024 | 1,500 |
| 2048 | 5,000 |
+--------------+------------+
This table is based on 150,000 SHA-1's per second, 50 RSA signs per
second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
sign per second for 4096 bit keys, 100 DSA signs per second for 1024
bit keys and 30 signs per second for 2048 bit keys.
Note that since RSA verifications are 10-100 times faster than
signatures (depending on key size), in the case of RSA the legal
values of iterations can substantially increase the cost of
verification.
8.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.
8.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
MUST be chosen and all hash values MUST be regenerated.
8.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
Laurie, et al. Expires August 5, 2006 [Page 16]
Internet-Draft nsec3 February 2006
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.
8.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 is 2^n.
An extreme hash value truncation would be truncating to the shortest
possible unique label value. This would be unwise, since the work
factor to produce second preimages would then approximate the size of
the zone (sketch of proof: if the zone has k entries, then the length
of the names when truncated down to uniqueness should be proportional
to log_2(k). Since the work factor to produce a second pre-image is
2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
C is some constant), i.e. C'k - a work factor of k).
Though the mentioned truncation can be maximized to a certain
extreme, the probability of collision increases exponentially for
every truncated bit. Given the low impact of hash value collisions
and limited space in DNS messages, the balance between truncation
profit and collision damage may be determined by local policy. Of
course, the size of the corresponding RRSIG RR is not reduced, so
truncation is of limited benefit.
Truncation could be signaled simply by reducing the length of the
first label in the ownername. Note that there would have to be a
corresponding reduction in the length of the Next Hashed Ownername
field.
8.4.4. Server Response to a Run-time Collision
In the astronomically unlikely event that a server is unable to prove
nonexistence because the hash of the name that does not exist
collides with a name that does exist, the server is obviously broken,
and should, therefore, return a response with an RCODE of 2 (server
failure).
Laurie, et al. Expires August 5, 2006 [Page 17]
Internet-Draft nsec3 February 2006
8.4.5. Parameters that Cover the Zone
Secondary servers (and perhaps other entities) need to reliably
determine which NSEC3 parameters (that is, hash, salt and iterations)
are present at every hashed ownername, in order to be able to choose
an appropriate set of NSEC3 records for negative responses. This is
indicated by the parameters at the apex: any set of parameters that
is used in an NSEC3 record whose original ownername is the apex of
the zone MUST be present throughout the zone.
A method to determine which NSEC3 in a complete chain corresponds to
the apex is to look for a NSEC3 RRset which has the SOA bit set in
the RDATA bit type maps field.
9. Performance Considerations
Iterated hashes 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.
10. IANA Considerations
IANA needs to allocate a RR type code for NSEC3 from the standard RR
type space (type XXX requested). IANA needs to open a new registry
for the NSEC3 Hash Functions. The range for this registry is 0-127.
Defined types are:
0 is reserved.
1 is SHA-1 ([13]).
127 is experimental.
11. Security Considerations
The NSEC3 records are still susceptible to dictionary attacks (i.e.
Laurie, et al. Expires August 5, 2006 [Page 18]
Internet-Draft nsec3 February 2006
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 enumerating 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.
The expense of this off-line attack can be chosen by setting the
number of iterations in the NSEC3 RR.
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.
Responses to queries where QNAME equals an NSEC3 ownername that has
no other types may be undetectably changed from a NOERROR/NODATA
response to a NAME ERROR response.
The Opt-In Flag (O) allows for unsigned names, in the form of
delegations to unsigned subzones, to exist within an otherwise signed
zone. All unsigned names are, by definition, insecure, and their
validity or existence cannot by cryptographically proven.
In general:
Records with unsigned names (whether existing or not) suffer from
the same vulnerabilities as records in an unsigned zone. These
vulnerabilities are described in more detail in [16] (note in
particular sections 2.3, "Name Games" and 2.6, "Authenticated
Denial").
Records with signed names have the same security whether or not
Opt-In is used.
Note that with or without Opt-In, an insecure delegation may be
undetectably altered by an attacker. Because of this, the primary
difference in security when using Opt-In is the loss of the ability
to prove the existence or nonexistence of an insecure delegation
Laurie, et al. Expires August 5, 2006 [Page 19]
Internet-Draft nsec3 February 2006
within the span of an Opt-In NSEC3 record.
In particular, this means that a malicious entity may be able to
insert or delete records with unsigned names. These records are
normally NS records, but this also includes signed wildcard
expansions (while the wildcard record itself is signed, its expanded
name is an unsigned name).
For example, if a resolver received the following response from the
example zone above:
Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
RCODE=NOERROR
Answer Section:
Authority Section:
DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
RRSIG DNSKEY
abcd... RRSIG NSEC3 ...
Additional Section:
The resolver would have no choice but to accept that the referral to
NS.FORGED. is valid. If a wildcard existed that would have been
expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
have undetectably removed it and replaced it with the forged
delegation.
Note that being able to add a delegation is functionally equivalent
to being able to add any record type: an attacker merely has to forge
a delegation to nameserver under his/her control and place whatever
records needed at the subzone apex.
While in particular cases, this issue may not present a significant
security problem, in general it should not be lightly dismissed.
Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
In particular, zone signing tools SHOULD NOT default to using Opt-In,
and MAY choose to not support Opt-In at all.
12. References
Laurie, et al. Expires August 5, 2006 [Page 20]
Internet-Draft nsec3 February 2006
12.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
[6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[7] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[11] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
September 2000.
[12] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
[13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
Laurie, et al. Expires August 5, 2006 [Page 21]
Internet-Draft nsec3 February 2006
12.2. Informative References
[14] Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
draft-vixie-dnssec-ter-01 (work in progress), June 2004.
[15] Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
October 2005.
[16] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
Editorial Comments
[] Although, strictly speaking, the names *did* exist.
[] Note that this method makes it impossible to detect
(extremely unlikely) hash collisions.
Appendix A. Example Zone
This is a zone showing its NSEC3 records. They can also be used as
test vectors for the hash algorithm.
The data in the example zone is currently broken, as it uses a
different base32 alphabet. This shall be fixed in the next release.
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.
Laurie, et al. Expires August 5, 2006 [Page 22]
Internet-Draft nsec3 February 2006
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
) ; 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 (
Laurie, et al. Expires August 5, 2006 [Page 23]
Internet-Draft nsec3 February 2006
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 (
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
Laurie, et al. Expires August 5, 2006 [Page 24]
Internet-Draft nsec3 February 2006
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
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
Laurie, et al. Expires August 5, 2006 [Page 25]
Internet-Draft nsec3 February 2006
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.
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 (
Laurie, et al. Expires August 5, 2006 [Page 26]
Internet-Draft nsec3 February 2006
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== )
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 August 5, 2006 [Page 27]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 28]
Internet-Draft nsec3 February 2006
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 August 5, 2006 [Page 29]
Internet-Draft nsec3 February 2006
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 August 5, 2006 [Page 30]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 31]
Internet-Draft nsec3 February 2006
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 hashing 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 other words, the
resolver first hashes example, checks for a matching NSEC3 ownername,
then hashes w.example, checks, and finally hashes w.x.example and
checks.
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 August 5, 2006 [Page 32]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 33]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 34]
Internet-Draft nsec3 February 2006
;; 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 the Opt-In Flag
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 August 5, 2006 [Page 35]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 36]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 37]
Internet-Draft nsec3 February 2006
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 August 5, 2006 [Page 38]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 39]
Internet-Draft nsec3 February 2006
;; 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 August 5, 2006 [Page 40]
Internet-Draft nsec3 February 2006
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
Roy Arends
Nominet
Laurie, et al. Expires August 5, 2006 [Page 41]
Internet-Draft nsec3 February 2006
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 (2006). 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 August 5, 2006 [Page 42]
