2353 lines
89 KiB
Plaintext
2353 lines
89 KiB
Plaintext
|
||
|
||
|
||
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
|
||
|
||
[Comment.1] Although, strictly speaking, the names *did* exist.
|
||
|
||
[Comment.2] 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]
|
||
|