2073 lines
78 KiB
Plaintext
2073 lines
78 KiB
Plaintext
|
||
|
||
|
||
Network Working Group B. Laurie
|
||
Internet-Draft G. Sisson
|
||
Expires: December 3, 2005 Nominet
|
||
R. Arends
|
||
Telematica Instituut
|
||
june 2005
|
||
|
||
|
||
DNSSEC Hash Authenticated Denial of Existence
|
||
draft-ietf-dnsext-nsec3-02
|
||
|
||
Status of this Memo
|
||
|
||
By submitting this Internet-Draft, each author represents that any
|
||
applicable patent or other IPR claims of which he or she is aware
|
||
have been or will be disclosed, and any of which he or she becomes
|
||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||
|
||
Internet-Drafts are working documents of the Internet Engineering
|
||
Task Force (IETF), its areas, and its working groups. Note that
|
||
other groups may also distribute working documents as Internet-
|
||
Drafts.
|
||
|
||
Internet-Drafts are draft documents valid for a maximum of six months
|
||
and may be updated, replaced, or obsoleted by other documents at any
|
||
time. It is inappropriate to use Internet-Drafts as reference
|
||
material or to cite them other than as "work in progress."
|
||
|
||
The list of current Internet-Drafts can be accessed at
|
||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||
|
||
The list of Internet-Draft Shadow Directories can be accessed at
|
||
http://www.ietf.org/shadow.html.
|
||
|
||
This Internet-Draft will expire on December 3, 2005.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2005).
|
||
|
||
Abstract
|
||
|
||
The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
|
||
used to provide authenticated denial of existence of DNS ownernames
|
||
and types; however, it permits any user to traverse a zone and obtain
|
||
a listing of all ownernames.
|
||
|
||
A complete zone file can be used either directly as a source of
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 1]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
probable e-mail addresses for spam, or indirectly as a key for
|
||
multiple WHOIS queries to reveal registrant data which many
|
||
registries (particularly in Europe) may be under strict legal
|
||
obligations to protect. Many registries therefore prohibit copying
|
||
of their zone file; however the use of NSEC RRs renders policies
|
||
unenforceable.
|
||
|
||
This document proposes a scheme which obscures original ownernames
|
||
while permitting authenticated denial of existence of non-existent
|
||
names. Non-authoritative delegation point NS RR types may be
|
||
excluded.
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
|
||
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
|
||
2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5
|
||
2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6
|
||
2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6
|
||
2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7
|
||
2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7
|
||
2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7
|
||
2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7
|
||
2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8
|
||
2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9
|
||
3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9
|
||
4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10
|
||
5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10
|
||
6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11
|
||
6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11
|
||
6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
|
||
6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12
|
||
6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13
|
||
6.4.1 Avoiding Hash Collisions during generation . . . . . . 14
|
||
6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14
|
||
6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14
|
||
7. Performance Considerations . . . . . . . . . . . . . . . . . . 15
|
||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
|
||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
|
||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
|
||
10.1 Normative References . . . . . . . . . . . . . . . . . . . 16
|
||
10.2 Informative References . . . . . . . . . . . . . . . . . . 17
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
|
||
A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 2]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23
|
||
B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23
|
||
B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25
|
||
B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26
|
||
B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28
|
||
B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29
|
||
B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30
|
||
B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31
|
||
B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
|
||
B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34
|
||
B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35
|
||
Intellectual Property and Copyright Statements . . . . . . . . 37
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 3]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
1. Introduction
|
||
|
||
The DNS Security Extensions (DNSSEC) introduced the NSEC Resource
|
||
Record (RR) for authenticated denial of existence. This document
|
||
introduces a new RR as an alternative to NSEC that provides measures
|
||
against zone traversal and allows for gradual expansion of
|
||
delegation-centric zones.
|
||
|
||
1.1 Rationale
|
||
|
||
The DNS Security Extensions included the NSEC RR to provide
|
||
authenticated denial of existence. Though the NSEC RR meets the
|
||
requirements for authenticated denial of existence, it introduced a
|
||
side-effect in that the contents of a zone can be enumerated. This
|
||
property introduces undesired policy issues.
|
||
|
||
A second problem was the requirement that the existence of all record
|
||
types in a zone - including delegation point NS record types - must
|
||
be accounted for, despite the fact that delegation point NS RRsets
|
||
are not authoritative and not signed. This requirement has a side-
|
||
effect that the overhead of delegation-centric signed zones is not
|
||
related to the increase in security of subzones. This requirement
|
||
does not allow delegation-centric zones size to grow in relation to
|
||
the growth of signed subzones.
|
||
|
||
In the past, solutions have been proposed as a measure against these
|
||
side effects but at the time were regarded as secondary over the need
|
||
to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter)
|
||
a graceful transition path to future enhancements is introduced,
|
||
while current DNSSEC deployment can continue. This document presents
|
||
the NSEC3 Resource Record which mitigates these issues with the NSEC
|
||
RR.
|
||
|
||
The reader is assumed to be familiar with the basic DNS concepts
|
||
described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
|
||
that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
|
||
[RFC2308].
|
||
|
||
1.2 Reserved Words
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119 [RFC2119].
|
||
|
||
1.3 Terminology
|
||
|
||
In this document the term "original ownername" refers to a standard
|
||
ownername. Because this proposal uses the result of a hash function
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 4]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
over the original (unmodified) ownername, this result is referred to
|
||
as "hashed ownername".
|
||
|
||
"Canonical ordering of the zone" means the order in which hashed
|
||
ownernames are arranged according to their numerical value, treating
|
||
the leftmost (lowest numbered) byte as the most significant byte.
|
||
|
||
2. The NSEC3 Resource Record
|
||
|
||
The NSEC3 RR provides Authenticated Denial of Existence for DNS
|
||
Resource Record Sets.
|
||
|
||
The NSEC3 Resource Record lists RR types present at the NSEC3 RR's
|
||
original ownername. It includes the next hashed ownername in the
|
||
canonical ordering of the zone. The complete set of NSEC3 RRs in a
|
||
zone indicates which RRsets exist for the original ownername of the
|
||
RRset and form a chain of hashed ownernames in the zone. This
|
||
information is used to provide authenticated denial of existence for
|
||
DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation
|
||
point NS RRsets can optionally be excluded. To provide protection
|
||
against zone traversal, the ownernames used in the NSEC3 RR are
|
||
cryptographic hashes of the original ownername prepended to the name
|
||
of the zone. The NSEC3 RR indicates which hash function is used to
|
||
construct the hash, which salt is used, and how many iterations of
|
||
the hash function are performed over the original ownername.
|
||
|
||
The ownername for the NSEC3 RR is the base32 encoding of the hashed
|
||
ownername.
|
||
|
||
The type value for the NSEC3 RR is XX.
|
||
|
||
The NSEC3 RR RDATA format is class independent.
|
||
|
||
The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
|
||
field. This is in the spirit of negative caching [RFC2308].
|
||
|
||
2.1 NSEC3 RDATA Wire Format
|
||
|
||
The RDATA of the NSEC3 RR is as shown below:
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 5]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
|
||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|A|Hash Function| Iterations |
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
| Salt Length | Salt /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
/ Next Hashed Ownername /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
/ Type Bit Maps /
|
||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
||
|
||
2.1.1 The Authoritative Only Flag Field
|
||
|
||
The Authoritative Only Flag field indicates whether the Type Bit Maps
|
||
include delegation point NS record types.
|
||
|
||
If the flag is set to 1, the NS RR type bit for a delegation point
|
||
ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR
|
||
type bit MUST be ignored during processing of the NSEC3 RR. The NS
|
||
RR type bit has no meaning in this context (it is not authoritative),
|
||
hence the NSEC3 does not contest the existence of a NS RRset for this
|
||
ownername. When a delegation is not secured, there exist no DS RR
|
||
type nor any other authoritative types for this delegation, hence the
|
||
unsecured delegation has no NSEC3 record associated. Please see the
|
||
Special Consideration section for implications for unsigned
|
||
delegations.
|
||
|
||
If the flag is set to 0, the NS RR type bit for a delegation point
|
||
ownername MUST be set if the NSEC3 covers a delegation, even though
|
||
the NS RR itself is not authoritative. This implies that all
|
||
delegations, signed or unsigned, have an NSEC3 record associated.
|
||
This behaviour is identical to NSEC behaviour.
|
||
|
||
2.1.2 The Hash Function Field
|
||
|
||
The Hash Function field identifies the cryptographic hash function
|
||
used to construct the hash-value.
|
||
|
||
This document defines Value 1 for SHA-1 and Value 127 for
|
||
experimental. All other values are reserved.
|
||
|
||
On reception, a resolver MUST discard an NSEC3 RR with an unknown
|
||
hash function value.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 6]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
2.1.3 The Iterations Field
|
||
|
||
The Iterations field defines the number of times the hash has been
|
||
iterated. More iterations results in greater resiliency of the hash
|
||
value against dictionary attacks, but at a higher cost for both the
|
||
server and resolver.
|
||
|
||
2.1.4 The Salt Length Field
|
||
|
||
The salt length field defines the length of the salt in octets.
|
||
|
||
2.1.5 The Salt Field
|
||
|
||
The Salt field is not present when the Salt Length Field has a value
|
||
of 0.
|
||
|
||
The Salt field is prepended to the original ownername before hashing
|
||
in order to defend against precalculated dictionary attacks.
|
||
|
||
The salt is also prepended during iterations of the hash function.
|
||
|
||
Note that although it is theoretically possible to cover the entire
|
||
possible ownername space with different salt values, it is
|
||
computationally infeasible to do so, and so there MUST be at least
|
||
one salt which is the same for all NSEC3 records. This means that no
|
||
matter what name is asked for in a query, it is guaranteed to be
|
||
possible to find a covering NSEC3 record. Note that this does not
|
||
preclude the use of two different salts at the same time - indeed
|
||
this may well occur naturally, due to rolling the salt value
|
||
periodically.
|
||
|
||
The salt value SHOULD be changed from time to time - this is to
|
||
prevent the use of a precomputed dictionary to reduce the cost of
|
||
enumeration.
|
||
|
||
2.1.6 The Next Hashed Ownername Field
|
||
|
||
The Next Hashed Ownername field contains the hash of the ownername of
|
||
the next RR in the canonical ordering of the hashed ownernames of the
|
||
zone. The value of the Next Hashed Ownername Field in the last NSEC3
|
||
record in the zone is the same as the ownername of the first NSEC3 RR
|
||
in the zone in canonical order.
|
||
|
||
Hashed ownernames of RRsets not authoritative for the given zone
|
||
(such as glue records) MUST NOT be listed in the Next Hashed
|
||
Ownername unless at least one authoritative RRset exists at the same
|
||
ownername.
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 7]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
Note that the Next Hashed Ownername field is not encoded, unlike the
|
||
NSEC3 RR's ownername. It is the unmodified binary hash value.
|
||
|
||
2.1.7 The list of Type Bit Map(s) Field
|
||
|
||
The Type Bit Maps field identifies the RRset types which exist at the
|
||
NSEC3 RR's ownername.
|
||
|
||
The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
|
||
generation, and MUST be ignored during processing.
|
||
|
||
The RR type space is split into 256 window blocks, each representing
|
||
the low-order 8 bits of the 16-bit RR type space. Each block that
|
||
has at least one active RR type is encoded using a single octet
|
||
window number (from 0 to 255), a single octet bitmap length (from 1
|
||
to 32) indicating the number of octets used for the window block's
|
||
bitmap, and up to 32 octets (256 bits) of bitmap.
|
||
|
||
Blocks are present in the NSEC3 RR RDATA in increasing numerical
|
||
order.
|
||
|
||
"|" denotes concatenation
|
||
|
||
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
|
||
|
||
Each bitmap encodes the low-order 8 bits of RR types within the
|
||
window block, in network bit order. The first bit is bit 0. For
|
||
window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
|
||
to RR type 2 (NS), and so forth. For window block 1, bit 1
|
||
corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
|
||
1, it indicates that an RRset of that type is present for the NSEC3
|
||
RR's ownername. If a bit is set to 0, it indicates that no RRset of
|
||
that type is present for the NSEC3 RR's ownername.
|
||
|
||
The RR type 2 (NS) is authoritative at the apex of a zone and is not
|
||
authoritative at delegation points. If the Authoritative Only Flag
|
||
is set to 1, the delegation point NS RR type MUST NOT be included in
|
||
the type bit maps. If the Authoritative Only Flag is set to 0, the
|
||
NS RR type at a delegation point MUST be included in the type bit
|
||
maps.
|
||
|
||
Since bit 0 in window block 0 refers to the non-existing RR type 0,
|
||
it MUST be set to 0. After verification, the validator MUST ignore
|
||
the value of bit 0 in window block 0.
|
||
|
||
Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929
|
||
[RFC2929] (section 3.1) or within the range reserved for assignment
|
||
only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 8]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
appear in zone data. If encountered, they must be ignored upon
|
||
reading.
|
||
|
||
Blocks with no types present MUST NOT be included. Trailing zero
|
||
octets in the bitmap MUST be omitted. The length of each block's
|
||
bitmap is determined by the type code with the largest numerical
|
||
value, within that block, among the set of RR types present at the
|
||
NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
|
||
be interpreted as zero octets.
|
||
|
||
2.2 The NSEC3 RR Presentation Format
|
||
|
||
The presentation format of the RDATA portion is as follows:
|
||
|
||
The Authoritative Only Field is represented as an unsigned decimal
|
||
integer. The value are either 0 or 1.
|
||
|
||
The Hash field is presented as the name of the hash or as an unsigned
|
||
decimal integer. The value has a maximum of 127.
|
||
|
||
The Iterations field is presented as an unsigned decimal integer.
|
||
|
||
The Salt Length field is not presented.
|
||
|
||
The Salt field is represented as a sequence of case-insensitive
|
||
hexadecimal digits. Whitespace is not allowed within the sequence.
|
||
The Salt Field is represented as 00 when the Salt Length field has
|
||
value 0.
|
||
|
||
The Next Hashed Ownername field is represented as a sequence of case-
|
||
insensitive base32 digits. Whitespace is allowed within the
|
||
sequence.
|
||
|
||
The List of Type Bit Map(s) Field is represented as a sequence of RR
|
||
type mnemonics. When the mnemonic is not known, the TYPE
|
||
representation as described in RFC 3597 [RFC3597] (section 5) MUST be
|
||
used.
|
||
|
||
3. Creating Additional NSEC3 RRs for Empty Non Terminals
|
||
|
||
In order to prove the non-existence of a record that might be covered
|
||
by a wildcard, it is necessary to prove the existence of its closest
|
||
encloser. A closest encloser might be an Empty Non Terminal.
|
||
|
||
Additional NSEC3 RRs are synthesized which cover every existing
|
||
intermediate label level. Additional NSEC3 RRs are identical in
|
||
format to NSEC3 RRs that cover existing RRs in the zone. The
|
||
difference is that the type-bit-maps only indicate the existence of
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 9]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
an NSEC3 RR type and an RRSIG RR type.
|
||
|
||
4. Calculation of the Hash
|
||
|
||
Define H(x) to be the hash of x using the hash function selected by
|
||
the NSEC3 record and || to indicate concatenation. Then define:
|
||
|
||
IH(salt,x,0)=H(x || salt)
|
||
|
||
IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
|
||
|
||
Then the calculated hash of an ownername is
|
||
IH(salt,ownername,iterations-1), where the ownername is the canonical
|
||
form.
|
||
|
||
The canonical form of the ownername is the wire format of the
|
||
ownername where:
|
||
1. The ownername is fully expanded (no DNS name compression) and
|
||
fully qualified;
|
||
2. All uppercase US-ASCII letters are replaced by the corresponding
|
||
lowercase US-ASCII letters;
|
||
3. If the ownername is a wildcard name, the ownername is in its
|
||
original unexpanded form, including the "*" label (no wildcard
|
||
substitution);
|
||
|
||
5. Including NSEC3 RRs in a Zone
|
||
|
||
Each owner name in the zone which has authoritative data or a secured
|
||
delegation point NS RRset MUST have an NSEC3 resource record.
|
||
|
||
An unsecured delegation point NS RRset MAY have an NSEC3 resource
|
||
record. This is different from NSEC records where an unsecured
|
||
delegation point NS RRset MUST have an NSEC record.
|
||
|
||
The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
|
||
value field in the zone SOA RR.
|
||
|
||
The type bitmap of every NSEC3 resource record in a signed zone MUST
|
||
indicate the presence of both the NSEC3 RR type itself and its
|
||
corresponding RRSIG RR type.
|
||
|
||
The bitmap for the NSEC3 RR at a delegation point requires special
|
||
attention. Bits corresponding to the delegation NS RRset and any
|
||
RRsets for which the parent zone has authoritative data MUST be set;
|
||
bits corresponding to any non-NS RRset for which the parent is not
|
||
authoritative MUST be clear.
|
||
|
||
The following steps describe the proper construction of NSEC3
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 10]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
records.
|
||
1. For each unique original owner name in the zone, add an NSEC3
|
||
RRset. This includes NSEC3 RRsets for unsigned delegation point
|
||
NS RRsets, unless the policy is to have Authoritative Only NSEC3
|
||
RRsets. The ownername of the NSEC3 RR is the hashed equivalent
|
||
of the original owner name, prepended to the zone name.
|
||
2. For each RRset at the original owner, set the corresponding bit
|
||
in the type bit map.
|
||
3. If the difference in number of labels between the apex and the
|
||
original ownername is greater then 1, additional NSEC3s need to
|
||
be added for every empty non-terminal between the apex and the
|
||
original ownername.
|
||
4. Sort the set of NSEC3 RRs.
|
||
5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next
|
||
Hashed Ownername of the last NSEC3 in the zone contains the value
|
||
of the hashed ownername of the first NSEC3 in the zone.
|
||
6. If the policy is to have authoritative only, set the
|
||
Authoritative Only bit in those NSEC3 RRs that cover unsecured
|
||
delegation points.
|
||
|
||
6. Special Considerations
|
||
|
||
The following paragraphs clarify specific behaviour explain special
|
||
considerations for implementations.
|
||
|
||
6.1 Delegation Points
|
||
|
||
This proposal introduces the Authoritative Only Flag which indicates
|
||
whether non authoritative delegation point NS records are included in
|
||
the type bit Maps. As discussed in paragraph 2.1.1, a flag value of
|
||
0 indicates that the interpretation of the type bit maps is identical
|
||
to NSEC records.
|
||
|
||
The following subsections describe behaviour when the flag value is
|
||
1.
|
||
|
||
6.1.1 Unsigned Delegations
|
||
|
||
Delegation point NS records are not authoritative. They are
|
||
authoritative in the delegated zone. No other data exists at the
|
||
ownername of an unsigned delegation point.
|
||
|
||
Since no authoritative data exist at this ownername, it is excluded
|
||
from the NSEC3 chain. This is an optimization, since it relieves the
|
||
zone of including an NSEC3 record and its associated signature for
|
||
this name.
|
||
|
||
An NSEC3 that denies existence of ownernames between X and X' with
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 11]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
the Authoritative Only Flag set to 1 can not be used to prove the
|
||
presence or the absence of delegation point NS records for unsigned
|
||
delegations in the interval (X, X'). The Authoritative Only Flag
|
||
effectively states No Contest on the presence of delegation point NS
|
||
resource records.
|
||
|
||
Since proof is absent, there exists a new attack vector. Unsigned
|
||
delegation point NS records can be deleted during a man in the middle
|
||
attack, effectively denying existence of the delegation. This is a
|
||
form of Denial of Service, where the victim has no information it is
|
||
under attack, since all signatures are valid and the fabricated
|
||
response form is a known type of response.
|
||
|
||
The only possible mitigation is to either not use this method, hence
|
||
proving existence or absence of unsigned delegations, or to sign all
|
||
delegations, regardless of whether the delegated zone is signed or
|
||
not.
|
||
|
||
A second attack vector exists in that an adversary is able to
|
||
successfully fabricate an (unsigned) response claiming a nonexistent
|
||
delegation exists.
|
||
|
||
The only possible mitigation is to mandate the signing of all
|
||
delegations.
|
||
|
||
6.2 Proving Nonexistence
|
||
|
||
If a wildcard resource record appears in a zone, its asterisk label
|
||
is treated as a literal symbol and is treated in the same way as any
|
||
other ownername for purposes of generating NSEC3 RRs. RFC 4035
|
||
[RFC4035] describes the impact of wildcards on authenticated denial
|
||
of existence.
|
||
|
||
In order to prove there exist no RRs for a domain, as well as no
|
||
source of synthesis, an RR must be shown for the closest encloser,
|
||
and non-existence must be shown for all closer labels and for the
|
||
wildcard at the closest encloser.
|
||
|
||
This can be done as follows. If the QNAME in the query is
|
||
omega.alfa.beta.example, and the closest encloser is beta.example
|
||
(the nearest ancestor to omega.alfa.beta.example), then the server
|
||
should return an NSEC3 that demonstrates the nonexistence of
|
||
alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
|
||
*.beta.example, and an NSEC3 that demonstrates the existence of
|
||
beta.example. This takes between one and three NSEC3 records, since
|
||
a single record can, by chance, prove more than one of these facts.
|
||
|
||
When a verifier checks this response, then the existence of
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 12]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
beta.example together with the non-existence of alfa.beta.example
|
||
proves that the closest encloser is indeed beta.example. The non-
|
||
existence of *.beta.example shows that there is no wildcard at the
|
||
closest encloser, and so no source of synthesis for
|
||
omega.alfa.beta.example. These two facts are sufficient to satisfy
|
||
the resolver that the QNAME cannot be resolved.
|
||
|
||
In practice, since the NSEC3 owner and next names are hashed, if the
|
||
server responds with an NSEC3 for beta.example, the resolver will
|
||
have to try successively longer names, starting with example, moving
|
||
to beta.example, alfa.beta.example, and so on, until one of them
|
||
hashes to a value that matches the interval (but not the ownername
|
||
nor next owner name) of one of the returned NSEC3s (this name will be
|
||
alfa.beta.example). Once it has done this, it knows the closest
|
||
encloser (i.e. beta.example), and can then easily check the other two
|
||
required proofs.
|
||
|
||
Note that it is not possible for one of the shorter names tried by
|
||
the resolver to be denied by one of the returned NSEC3s, since, by
|
||
definition, all these names exist and so cannot appear within the
|
||
range covered by an NSEC3. Note, however, that the first name that
|
||
the resolver tries MUST be the apex of the zone, since names above
|
||
the apex could be denied by one of the returned NSEC3s.
|
||
|
||
6.3 Salting
|
||
|
||
Augmenting original ownernames with salt before hashing increases the
|
||
cost of a dictionary of pre-generated hash-values. For every bit of
|
||
salt, the cost of the dictionary doubles. The NSEC3 RR can use a
|
||
maximum of 2040 bits of salt, multiplying the cost by 2^2040.
|
||
|
||
There MUST be a complete set of NSEC3s for the zone using the same
|
||
salt value. The salt value for each NSEC3 RR MUST be equal for a
|
||
single version of the zone.
|
||
|
||
The salt SHOULD be changed every time the zone is resigned to prevent
|
||
precomputation using a single salt.
|
||
|
||
6.4 Hash Collision
|
||
|
||
Hash collisions occur when different messages have the same hash
|
||
value. The expected number of domain names needed to give a 1 in 2
|
||
chance of a single collision is about 2^(n/2) for a hash of length n
|
||
bits (i.e. 2^80 for SHA-1). Though this probability is extremely
|
||
low, the following paragraphs deal with avoiding collisions and
|
||
assessing possible damage in the event of an attack using hash
|
||
collisions.
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 13]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
6.4.1 Avoiding Hash Collisions during generation
|
||
|
||
During generation of NSEC3 RRs, hash values are supposedly unique.
|
||
In the (academic) case of a collision occurring, an alternative salt
|
||
SHOULD be chosen and all hash values SHOULD be regenerated.
|
||
|
||
If hash values are not regenerated on collision, the NSEC3 RR MUST
|
||
list all authoritative RR types that exist for both owners, to avoid
|
||
a replay attack, spoofing an existing type as non-existent.
|
||
|
||
6.4.2 Second Preimage Requirement Analysis
|
||
|
||
A cryptographic hash function has a second-preimage resistance
|
||
property. The second-preimage resistance property means that it is
|
||
computationally infeasible to find another message with the same hash
|
||
value as a given message, i.e. given preimage X, to find a second
|
||
preimage X' <> X such that hash(X) = hash(X'). The work factor for
|
||
finding a second preimage is of the order of 2^160 for SHA-1. To
|
||
mount an attack using an existing NSEC3 RR, an adversary needs to
|
||
find a second preimage.
|
||
|
||
Assuming an adversary is capable of mounting such an extreme attack,
|
||
the actual damage is that a response message can be generated which
|
||
claims that a certain QNAME (i.e. the second pre-image) does exist,
|
||
while in reality QNAME does not exist (a false positive), which will
|
||
either cause a security aware resolver to re-query for the non-
|
||
existent name, or to fail the initial query. Note that the adversary
|
||
can't mount this attack on an existing name but only on a name that
|
||
the adversary can't choose and does not yet exist.
|
||
|
||
6.4.3 Possible Hash Value Truncation Method
|
||
|
||
The previous sections outlined the low probability and low impact of
|
||
a second-preimage attack. When impact and probability are low, while
|
||
space in a DNS message is costly, truncation is tempting. Truncation
|
||
might be considered to allow for shorter ownernames and rdata for
|
||
hashed labels. In general, if a cryptographic hash is truncated to n
|
||
bits, then the expected number of domains required to give a 1 in 2
|
||
probability of a single collision is approximately 2^(n/2) and the
|
||
work factor to produce a second preimage resistance is 2^n.
|
||
|
||
An extreme hash value truncation would be truncating to the shortest
|
||
possible unique label value. Considering that hash values are
|
||
presented in base32, which represents 5 bits per label character,
|
||
truncation must be done on a 5 bit boundary. This would be unwise,
|
||
since the work factor to produce collisions would then approximate
|
||
the size of the zone.
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 14]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
Though the mentioned truncation can be maximized to a certain
|
||
extreme, the probability of collision increases exponentially for
|
||
every truncated bit. Given the low impact of hash value collisions
|
||
and limited space in DNS messages, the balance between truncation
|
||
profit and collision damage may be determined by local policy. Of
|
||
course, the size of the corresponding RRSIG RR is not reduced, so
|
||
truncation is of limited benefit.
|
||
|
||
Truncation could be signalled simply by reducing the length of the
|
||
first label in the ownername. Note that there would have to be a
|
||
corresponding reduction in the length of the Next Hashed Ownername
|
||
field.
|
||
|
||
7. Performance Considerations
|
||
|
||
Iterated hashes will obviously impose a performance penalty on both
|
||
authoritative servers and resolvers. Therefore, the number of
|
||
iterations should be carefully chosen. In particular it should be
|
||
noted that a high value for iterations gives an attacker a very good
|
||
denial of service attack, since the attacker need not bother to
|
||
verify the results of their queries, and hence has no performance
|
||
penalty of his own.
|
||
|
||
On the other hand, nameservers with low query rates and limited
|
||
bandwidth are already subject to a bandwidth based denial of service
|
||
attack, since responses are typically an order of magnitude larger
|
||
than queries, and hence these servers may choose a high value of
|
||
iterations in order to increase the difficulty of offline attempts to
|
||
enumerate their namespace without significantly increasing their
|
||
vulnerability to denial of service attacks.
|
||
|
||
8. IANA Considerations
|
||
|
||
IANA has to create a new registry for NSEC3 Hash Functions. The
|
||
range for this registry is 0-127. Value 0 is the identity function.
|
||
Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value
|
||
127 is marked as Experimental.
|
||
|
||
9. Security Considerations
|
||
|
||
The NSEC3 records are still susceptible to dictionary attacks (i.e.
|
||
the attacker retrieves all the NSEC3 records, then calculates the
|
||
hashes of all likely domain names, comparing against the hashes found
|
||
in the NSEC3 records, and thus enumerating the zone). These are
|
||
substantially more expensive than traversing the original NSEC
|
||
records would have been, and in any case, such an attack could also
|
||
be used directly against the name server itself by performing queries
|
||
for all likely names, though this would obviously be more detectable.
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 15]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
The expense of this off-line attack can be chosen by setting the
|
||
number of iterations in the NSEC3 RR.
|
||
|
||
High-value domains are also susceptible to a precalculated dictionary
|
||
attack - that is, a list of hashes for all likely names is computed
|
||
once, then NSEC3 is scanned periodically and compared against the
|
||
precomputed hashes. This attack is prevented by changing the salt on
|
||
a regular basis.
|
||
|
||
Walking the NSEC3 RRs will reveal the total number of records in the
|
||
zone, and also what types they are. This could be mitigated by
|
||
adding dummy entries, but certainly an upper limit can always be
|
||
found.
|
||
|
||
Hash collisions may occur. If they do, it will be impossible to
|
||
prove the non-existence of the colliding domain - however, this is
|
||
fantastically unlikely, and, in any case, DNSSEC already relies on
|
||
SHA-1 to not collide.
|
||
|
||
10. References
|
||
|
||
10.1 Normative References
|
||
|
||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
|
||
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
|
||
RFC 2136, April 1997.
|
||
|
||
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
|
||
NCACHE)", RFC 2308, March 1998.
|
||
|
||
[RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
|
||
"Domain Name System (DNS) IANA Considerations", BCP 42,
|
||
RFC 2929, September 2000.
|
||
|
||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||
(RR) Types", RFC 3597, September 2003.
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 16]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements",
|
||
RFC 4033, March 2005.
|
||
|
||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Resource Records for the DNS Security Extensions",
|
||
RFC 4034, March 2005.
|
||
|
||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Protocol Modifications for the DNS Security
|
||
Extensions", RFC 4035, March 2005.
|
||
|
||
10.2 Informative References
|
||
|
||
[I-D.ietf-dnsext-trustupdate-threshold]
|
||
Ihren, J., "An In-Band Rollover Mechanism and an Out-Of-
|
||
Band Priming Method for DNSSEC Trust Anchors.",
|
||
draft-ietf-dnsext-trustupdate-threshold-00 (work in
|
||
progress), October 2004.
|
||
|
||
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
|
||
3", BCP 9, RFC 2026, October 1996.
|
||
|
||
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
|
||
Procedures", BCP 25, RFC 2418, September 1998.
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Ben Laurie
|
||
Nominet
|
||
17 Perryn Road
|
||
London W3 7LR
|
||
England
|
||
|
||
Phone: +44 (20) 8735 0686
|
||
Email: ben@algroup.co.uk
|
||
|
||
|
||
Geoffrey Sisson
|
||
Nominet
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 17]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
Roy Arends
|
||
Telematica Instituut
|
||
Brouwerijstraat 1
|
||
7523 XC Enschede
|
||
The Netherlands
|
||
|
||
Phone: +31 (53) 485 0485
|
||
Email: roy.arends@telin.nl
|
||
|
||
Appendix A. Example Zone
|
||
|
||
This is a zone showing its NSEC3 records. They can also be used as
|
||
test vectors for the hash algorithm.
|
||
|
||
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1
|
||
3600
|
||
300
|
||
3600000
|
||
3600 )
|
||
3600 RRSIG SOA 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
|
||
mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
|
||
qYIt90txzE/4+g== )
|
||
3600 NS ns1.example.
|
||
3600 NS ns2.example.
|
||
3600 RRSIG NS 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
|
||
m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
|
||
1SH5r/wfjuCg+g== )
|
||
3600 MX 1 xx.example.
|
||
3600 RRSIG MX 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
|
||
NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
|
||
S/o/g5C8VM6ftQ== )
|
||
3600 DNSKEY 257 3 5 (
|
||
AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
|
||
cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
|
||
zsYKWJ7BvR2894hX
|
||
) ; Key ID = 21960
|
||
3600 DNSKEY 256 3 5 (
|
||
AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
|
||
5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
|
||
ExXT48OGGdbfIme5
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 18]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
) ; Key ID = 62699
|
||
3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
|
||
xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
|
||
mTkunTYzqWJrmQ== )
|
||
3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
|
||
20050612112304 21960 example.
|
||
SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
|
||
ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
|
||
3w7ZY2UWyYIvpw== )
|
||
5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
7nomf47k3vlidh4vxahhpp47l3tgv7a2
|
||
NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
|
||
Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
|
||
sb7KfbaUo/vzAg== )
|
||
7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
|
||
MX NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
|
||
ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
|
||
MEFQmc/gEuxojA== )
|
||
a.example. 3600 IN NS ns1.a.example.
|
||
3600 IN NS ns2.a.example.
|
||
3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
|
||
766A6A4837206C )
|
||
3600 RRSIG DS 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
|
||
cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
|
||
0kx7rGKTc3RQDA== )
|
||
ns1.a.example. 3600 IN A 192.0.2.5
|
||
ns2.a.example. 3600 IN A 192.0.2.6
|
||
ai.example. 3600 IN A 192.0.2.9
|
||
3600 RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
|
||
6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
|
||
ZXW5S+1VjMZYzQ== )
|
||
3600 HINFO "KLH-10" "ITS"
|
||
3600 RRSIG HINFO 5 2 3600 20050712112304 (
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 19]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
20050612112304 62699 example.
|
||
AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
|
||
tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
|
||
VGNmbgPnqDVPiA== )
|
||
3600 AAAA 2001:db8:0:0:0:0:f00:baa9
|
||
3600 RRSIG AAAA 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
|
||
ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
|
||
l5/UqLCJJ9BDMg== )
|
||
b.example. 3600 IN NS ns1.b.example.
|
||
3600 IN NS ns2.b.example.
|
||
ns1.b.example. 3600 IN A 192.0.2.7
|
||
ns2.b.example. 3600 IN A 192.0.2.8
|
||
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
gmnfcccja7wkax3iv26bs75myptje3qk
|
||
MX DNSKEY NS SOA NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
|
||
C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
|
||
MOiKMSHozVebqw== )
|
||
gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
|
||
DS NS NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
|
||
ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
|
||
OwQBGbOegrW/Zw== )
|
||
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
kcll7fqfnisuhfekckeeqnmbbd4maanu
|
||
NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
|
||
IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
|
||
94Zbq3k8lgdpZA== )
|
||
kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
|
||
deadbeaf
|
||
n42hbhnjj333xdxeybycax5ufvntux5d
|
||
MX NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 20]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
|
||
TOLtc5jPrkL4zQ== )
|
||
n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
nimwfwcnbeoodmsc6npv3vuaagaevxxu
|
||
A NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
|
||
91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
|
||
xFPFGRIW3wKnrA== )
|
||
nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
vhgwr2qgykdkf4m6iv6vkagbxozphazr
|
||
HINFO A AAAA NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
|
||
z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
|
||
jL33Wm1p07TBdw== )
|
||
ns1.example. 3600 A 192.0.2.1
|
||
3600 RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
|
||
BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
|
||
nWWLepz1PjjShQ== )
|
||
ns2.example. 3600 A 192.0.2.2
|
||
3600 RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
|
||
P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
|
||
AkeTJu3J3auUiA== )
|
||
vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
wbyijvpnyj33pcpi3i44ecnibnaj7eiw
|
||
HINFO A AAAA NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
|
||
kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
|
||
5SNSHIyfpfsi6A== )
|
||
*.w.example. 3600 MX 1 ai.example.
|
||
3600 RRSIG MX 5 3 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
|
||
xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
|
||
gQlgxEwhvQDEaQ== )
|
||
x.w.example. 3600 MX 1 xx.example.
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 21]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
3600 RRSIG MX 5 3 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
|
||
lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
|
||
U9VazOa1KEIq1w== )
|
||
x.y.w.example. 3600 MX 1 xx.example.
|
||
3600 RRSIG MX 5 4 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
|
||
uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
|
||
9VrQvJjwbllAfA== )
|
||
wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
|
||
A NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
|
||
ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
|
||
oorBv4xkb0flXw== )
|
||
xx.example. 3600 A 192.0.2.10
|
||
3600 RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
|
||
tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
|
||
cxwCXWj82GVGdw== )
|
||
3600 HINFO "KLH-10" "TOPS-20"
|
||
3600 RRSIG HINFO 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
|
||
OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
|
||
KMf4DgNBDj+dIQ== )
|
||
3600 AAAA 2001:db8:0:0:0:0:f00:baaa
|
||
3600 RRSIG AAAA 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
|
||
w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
|
||
rzKKwb8J04/ILw== )
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
|
||
deadbeaf
|
||
5pe7ctl7pfs2cilroy5dcofx4rcnlypd
|
||
MX NSEC3 RRSIG )
|
||
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
|
||
7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
|
||
OcFlrPGPMm48/A== )
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 22]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
Appendix B. Example Responses
|
||
|
||
The examples in this section show response messages using the signed
|
||
zone example in Appendix A.
|
||
|
||
B.1 answer
|
||
|
||
A successful query to an authoritative server.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 23]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
x.w.example. IN MX
|
||
|
||
;; Answer
|
||
x.w.example. 3600 IN MX 1 xx.example.
|
||
x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
|
||
lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
|
||
U9VazOa1KEIq1w== )
|
||
|
||
;; Authority
|
||
example. 3600 IN NS ns1.example.
|
||
example. 3600 IN NS ns2.example.
|
||
example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
|
||
m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
|
||
1SH5r/wfjuCg+g== )
|
||
|
||
;; Additional
|
||
xx.example. 3600 IN A 192.0.2.10
|
||
xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
|
||
tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
|
||
cxwCXWj82GVGdw== )
|
||
xx.example. 3600 IN AAAA 2001:db8::f00:baaa
|
||
xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
|
||
w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
|
||
rzKKwb8J04/ILw== )
|
||
ns1.example. 3600 IN A 192.0.2.1
|
||
ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
|
||
BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
|
||
nWWLepz1PjjShQ== )
|
||
ns2.example. 3600 IN A 192.0.2.2
|
||
ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
|
||
P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
|
||
AkeTJu3J3auUiA== )
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 24]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
The query returned an MX RRset for "x.w.example". The corresponding
|
||
RRSIG RR indicates that the MX RRset was signed by an "example"
|
||
DNSKEY with algorithm 5 and key tag 62699. The resolver needs the
|
||
corresponding DNSKEY RR in order to authenticate this answer. The
|
||
discussion below describes how a resolver might obtain this DNSKEY
|
||
RR.
|
||
|
||
The RRSIG RR indicates the original TTL of the MX RRset was 3600,
|
||
and, for the purpose of authentication, the current TTL is replaced
|
||
by 3600. The RRSIG RR's labels field value of 3 indicates that the
|
||
answer was not the result of wildcard expansion. The "x.w.example"
|
||
MX RRset is placed in canonical form, and, assuming the current time
|
||
falls between the signature inception and expiration dates, the
|
||
signature is authenticated.
|
||
|
||
B.1.1 Authenticating the Example DNSKEY RRset
|
||
|
||
This example shows the logical authentication process that starts
|
||
from a configured root DNSKEY RRset (or DS RRset) and moves down the
|
||
tree to authenticate the desired "example" DNSKEY RRset. Note that
|
||
the logical order is presented for clarity. An implementation may
|
||
choose to construct the authentication as referrals are received or
|
||
to construct the authentication chain only after all RRsets have been
|
||
obtained, or in any other combination it sees fit. The example here
|
||
demonstrates only the logical process and does not dictate any
|
||
implementation rules.
|
||
|
||
We assume the resolver starts with a configured DNSKEY RRset for the
|
||
root zone (or a configured DS RRset for the root zone). The resolver
|
||
checks whether this configured DNSKEY RRset is present in the root
|
||
DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
|
||
RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
|
||
root DNSKEY RRset, and whether the signature lifetime is valid. If
|
||
all these conditions are met, all keys in the DNSKEY RRset are
|
||
considered authenticated. The resolver then uses one (or more) of
|
||
the root DNSKEY RRs to authenticate the "example" DS RRset. Note
|
||
that the resolver may have to query the root zone to obtain the root
|
||
DNSKEY RRset or "example" DS RRset.
|
||
|
||
Once the DS RRset has been authenticated using the root DNSKEY, the
|
||
resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
|
||
RR that matches one of the authenticated "example" DS RRs. If such a
|
||
matching "example" DNSKEY is found, the resolver checks whether this
|
||
DNSKEY RR has signed the "example" DNSKEY RRset and the signature
|
||
lifetime is valid. If these conditions are met, all keys in the
|
||
"example" DNSKEY RRset are considered authenticated.
|
||
|
||
Finally, the resolver checks that some DNSKEY RR in the "example"
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 25]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
|
||
DNSKEY is used to authenticate the RRSIG included in the response.
|
||
If multiple "example" DNSKEY RRs match this algorithm and key tag,
|
||
then each DNSKEY RR is tried, and the answer is authenticated if any
|
||
of the matching DNSKEY RRs validate the signature as described above.
|
||
|
||
B.2 Name Error
|
||
|
||
An authoritative name error. The NSEC3 RRs prove that the name does
|
||
not exist and that no covering wildcard exists.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 26]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=3
|
||
;;
|
||
;; Question
|
||
a.c.x.w.example. IN A
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
|
||
mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
|
||
qYIt90txzE/4+g== )
|
||
7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
|
||
MX NSEC3 RRSIG )
|
||
7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
|
||
ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
|
||
MEFQmc/gEuxojA== )
|
||
nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
vhgwr2qgykdkf4m6iv6vkagbxozphazr
|
||
HINFO A AAAA NSEC3 RRSIG )
|
||
nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
|
||
z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
|
||
jL33Wm1p07TBdw== )
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
The query returned two NSEC3 RRs that prove that the requested data
|
||
does not exist and no wildcard applies. The negative reply is
|
||
authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are
|
||
authenticated in a manner identical to that of the MX RRset discussed
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 27]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
above. At least one of the owner names of the NSEC3 RRs will match
|
||
the closest encloser. At least one of the NSEC3 RRs prove that there
|
||
exists no longer name. At least one of the NSEC3 RRs prove that
|
||
there exists no wildcard RRsets that should have been expanded. The
|
||
closest encloser can be found by hasing the apex ownername (The SOA
|
||
RR's ownername, or the ownername of the DNSKEY RRset referred by an
|
||
RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
|
||
if that fails, continue by adding labels.
|
||
|
||
In the above example, the name 'x.w.example' hashes to
|
||
'7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might
|
||
be the closest encloser. To prove that 'c.x.w.example' and
|
||
'*.x.w.example' do not exists, these names are hashed to respectively
|
||
'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
|
||
'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that
|
||
these hashed ownernames do not exists, since the names are within the
|
||
given intervals.
|
||
|
||
B.3 No Data Error
|
||
|
||
A "no data" response. The NSEC3 RR proves that the name exists and
|
||
that the requested RR type does not.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 28]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
ns1.example. IN MX
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
|
||
mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
|
||
qYIt90txzE/4+g== )
|
||
wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
|
||
A NSEC3 RRSIG )
|
||
wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
|
||
ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
|
||
oorBv4xkb0flXw== )
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
The query returned an NSEC3 RR that proves that the requested name
|
||
exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
|
||
but the requested RR type does not exist (type MX is absent in the
|
||
type code list of the NSEC RR). The negative reply is authenticated
|
||
by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
|
||
identical to that of the MX RRset discussed above.
|
||
|
||
B.3.1 No Data Error, Empty Non-Terminal
|
||
|
||
A "no data" response because of an empty non-terminal. The NSEC3 RR
|
||
proves that the name exists and that the requested RR type does not.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 29]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
y.w.example. IN A
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
|
||
mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
|
||
qYIt90txzE/4+g== )
|
||
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
kcll7fqfnisuhfekckeeqnmbbd4maanu
|
||
NSEC3 RRSIG )
|
||
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
|
||
IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
|
||
94Zbq3k8lgdpZA== )
|
||
|
||
The query returned an NSEC3 RR that proves that the requested name
|
||
exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
|
||
but the requested RR type does not exist (Type A is absent in the
|
||
type-bit-maps of the NSEC3 RR). The negative reply is authenticated
|
||
by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
|
||
identical to that of the MX RRset discussed above. Note that, unlike
|
||
generic empty non terminal proof using NSECs, this is identical to
|
||
proving a No Data Error. This example is solely mentioned to be
|
||
complete.
|
||
|
||
B.4 Referral to Signed Zone
|
||
|
||
Referral to a signed zone. The DS RR contains the data which the
|
||
resolver will need to validate the corresponding DNSKEY RR in the
|
||
child zone's apex.
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 30]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR DO RCODE=0
|
||
;;
|
||
|
||
;; Question
|
||
mc.a.example. IN MX
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
a.example. 3600 IN NS ns1.a.example.
|
||
a.example. 3600 IN NS ns2.a.example.
|
||
a.example. 3600 IN DS 58470 5 1 (
|
||
3079F1593EBAD6DC121E202A8B766A6A4837
|
||
206C )
|
||
a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
|
||
cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
|
||
0kx7rGKTc3RQDA== )
|
||
|
||
;; Additional
|
||
ns1.a.example. 3600 IN A 192.0.2.5
|
||
ns2.a.example. 3600 IN A 192.0.2.6
|
||
|
||
The query returned a referral to the signed "a.example." zone. The
|
||
DS RR is authenticated in a manner identical to that of the MX RRset
|
||
discussed above. This DS RR is used to authenticate the "a.example"
|
||
DNSKEY RRset.
|
||
|
||
Once the "a.example" DS RRset has been authenticated using the
|
||
"example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
|
||
for some "a.example" DNSKEY RR that matches the DS RR. If such a
|
||
matching "a.example" DNSKEY is found, the resolver checks whether
|
||
this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
|
||
the signature lifetime is valid. If all these conditions are met,
|
||
all keys in the "a.example" DNSKEY RRset are considered
|
||
authenticated.
|
||
|
||
B.5 Referral to Unsigned Zone using Opt-In
|
||
|
||
Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that
|
||
nothing for this delegation was signed in the parent zone. There is
|
||
no proof that the delegation exists
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 31]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR DO RCODE=0
|
||
;;
|
||
;; Question
|
||
mc.b.example. IN MX
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
b.example. 3600 IN NS ns1.b.example.
|
||
b.example. 3600 IN NS ns2.b.example.
|
||
kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
|
||
deadbeaf
|
||
n42hbhnjj333xdxeybycax5ufvntux5d
|
||
MX NSEC3 RRSIG )
|
||
kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
|
||
IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
|
||
TOLtc5jPrkL4zQ== )
|
||
|
||
;; Additional
|
||
ns1.b.example. 3600 IN A 192.0.2.7
|
||
ns2.b.example. 3600 IN A 192.0.2.8
|
||
|
||
The query returned a referral to the unsigned "b.example." zone. The
|
||
NSEC3 proves that no authentication leads from "example" to
|
||
"b.example", since the hash of "b.example"
|
||
("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
|
||
the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a
|
||
manner identical to that of the MX RRset discussed above.
|
||
|
||
B.6 Wildcard Expansion
|
||
|
||
A successful query that was answered via wildcard expansion. The
|
||
label count in the answer's RRSIG RR indicates that a wildcard RRset
|
||
was expanded to produce this response, and the NSEC3 RR proves that
|
||
no closer match exists in the zone.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 32]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
a.z.w.example. IN MX
|
||
|
||
;; Answer
|
||
a.z.w.example. 3600 IN MX 1 ai.example.
|
||
a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
|
||
xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
|
||
gQlgxEwhvQDEaQ== )
|
||
;; Authority
|
||
example. 3600 NS ns1.example.
|
||
example. 3600 NS ns2.example.
|
||
example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
|
||
m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
|
||
1SH5r/wfjuCg+g== )
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
5pe7ctl7pfs2cilroy5dcofx4rcnlypd
|
||
MX NSEC3 RRSIG )
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
|
||
7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
|
||
OcFlrPGPMm48/A== )
|
||
;; Additional
|
||
ai.example. 3600 IN A 192.0.2.9
|
||
ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
|
||
6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
|
||
ZXW5S+1VjMZYzQ== )
|
||
ai.example. 3600 AAAA 2001:db8::f00:baa9
|
||
ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
|
||
ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
|
||
l5/UqLCJJ9BDMg== )
|
||
|
||
The query returned an answer that was produced as a result of
|
||
wildcard expansion. The answer section contains a wildcard RRset
|
||
expanded as it would be in a traditional DNS response, and the
|
||
corresponding RRSIG indicates that the expanded wildcard MX RRset was
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 33]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
|
||
The RRSIG indicates that the original TTL of the MX RRset was 3600,
|
||
and, for the purpose of authentication, the current TTL is replaced
|
||
by 3600. The RRSIG labels field value of 2 indicates that the answer
|
||
is the result of wildcard expansion, as the "a.z.w.example" name
|
||
contains 4 labels. The name "a.z.w.example" is replaced by
|
||
"*.w.example", the MX RRset is placed in canonical form, and,
|
||
assuming that the current time falls between the signature inception
|
||
and expiration dates, the signature is authenticated.
|
||
|
||
The NSEC3 proves that no closer match (exact or closer wildcard)
|
||
could have been used to answer this query, and the NSEC3 RR must also
|
||
be authenticated before the answer is considered valid.
|
||
|
||
B.7 Wildcard No Data Error
|
||
|
||
A "no data" response for a name covered by a wildcard. The NSEC3 RRs
|
||
prove that the matching wildcard name does not have any RRs of the
|
||
requested type and that no closer match exists in the zone.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 34]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
a.z.w.example. IN AAAA
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
|
||
mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
|
||
qYIt90txzE/4+g== )
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
5pe7ctl7pfs2cilroy5dcofx4rcnlypd
|
||
MX NSEC3 RRSIG )
|
||
zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
|
||
7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
|
||
OcFlrPGPMm48/A== )
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
The query returned NSEC3 RRs that prove that the requested data does
|
||
not exist and no wildcard applies. The negative reply is
|
||
authenticated by verifying both NSEC3 RRs.
|
||
|
||
B.8 DS Child Zone No Data Error
|
||
|
||
A "no data" response for a QTYPE=DS query that was mistakenly sent to
|
||
a name server for the child zone.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 35]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
;; Header: QR AA DO RCODE=0
|
||
;;
|
||
;; Question
|
||
example. IN DS
|
||
|
||
;; Answer
|
||
;; (empty)
|
||
|
||
;; Authority
|
||
example. 3600 IN SOA ns1.example. bugs.x.w.example. (
|
||
1
|
||
3600
|
||
300
|
||
3600000
|
||
3600
|
||
)
|
||
example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
|
||
20050612112304 62699 example.
|
||
RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
|
||
mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
|
||
qYIt90txzE/4+g== )
|
||
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
|
||
deadbeaf
|
||
gmnfcccja7wkax3iv26bs75myptje3qk
|
||
MX DNSKEY NS SOA NSEC3 RRSIG )
|
||
dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
|
||
5 2 3600 20050712112304
|
||
20050612112304 62699 example.
|
||
VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
|
||
C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
|
||
MOiKMSHozVebqw== )
|
||
|
||
;; Additional
|
||
;; (empty)
|
||
|
||
The query returned NSEC RRs that shows the requested was answered by
|
||
a child server ("example" server). The NSEC RR indicates the
|
||
presence of an SOA RR, showing that the answer is from the child .
|
||
Queries for the "example" DS RRset should be sent to the parent
|
||
servers ("root" servers).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 36]
|
||
|
||
Internet-Draft nsec3 june 2005
|
||
|
||
|
||
Intellectual Property Statement
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
Disclaimer of Validity
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2005). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78, and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
Laurie, et al. Expires December 3, 2005 [Page 37]
|
||
|