Network Working Group B. Laurie
Internet-Draft G. Sisson
-Expires: December 3, 2005 Nominet
- R. Arends
- Telematica Instituut
- june 2005
+Expires: August 5, 2006 R. Arends
+ Nominet
+ February 2006
DNSSEC Hash Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-02
+ draft-ietf-dnsext-nsec3-04
Status of this Memo
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.
+ This Internet-Draft will expire on August 5, 2006.
Copyright Notice
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
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
+ 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 December 3, 2005 [Page 1]
-\f
-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.
+Laurie, et al. Expires August 5, 2006 [Page 1]
+\f
+Internet-Draft nsec3 February 2006
- 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]
+ 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]
\f
-Internet-Draft nsec3 june 2005
+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
+
+
+
- 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]
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 3]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
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
+1.1. Rationale
The DNS Security Extensions included the NSEC RR to provide
authenticated denial of existence. Though the NSEC RR meets the
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].
+ 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.
-1.2 Reserved Words
+ 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 [RFC2119].
+ document are to be interpreted as described in RFC 2119 [9].
-1.3 Terminology
+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
+ 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 December 3, 2005 [Page 4]
+Laurie, et al. Expires August 5, 2006 [Page 4]
\f
-Internet-Draft nsec3 june 2005
+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".
- "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.
+ "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].
-2. The NSEC3 Resource Record
+ An "empty non-terminal" is a domain name that owns no resource
+ records but has subdomains that do.
- The NSEC3 RR provides Authenticated Denial of Existence for DNS
- Resource Record Sets.
+ 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.
- 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.
+ "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
+ specified in RFC 3548bis [15].
- The ownername for the NSEC3 RR is the base32 encoding of the hashed
- ownername.
- The type value for the NSEC3 RR is XX.
+2. NSEC versus NSEC3
- The NSEC3 RR RDATA format is class independent.
+ 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.
- 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
+3. The NSEC3 Resource Record
- The RDATA of the NSEC3 RR is as shown below:
+ 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]
+\f
+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.
-Laurie, et al. Expires December 3, 2005 [Page 5]
-\f
-Internet-Draft nsec3 june 2005
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |A|Hash Function| Iterations |
+ | Hash Function |O| Iterations |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt Length | Salt /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Maps /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ "O" is the Opt-In Flag field.
-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
+3.1.1. 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.
+ The values are as defined for the DS record (see RFC 3658 [10]).
- On reception, a resolver MUST discard an NSEC3 RR with an unknown
- hash function value.
+ On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
+ function value.
+Laurie, et al. Expires August 5, 2006 [Page 6]
+\f
+Internet-Draft nsec3 February 2006
+
+3.1.2. The Opt-In Flag Field
-Laurie, et al. Expires December 3, 2005 [Page 6]
+ 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]
\f
-Internet-Draft nsec3 june 2005
+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.
-2.1.3 The Iterations Field
+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.
+ 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.
-2.1.4 The Salt Length Field
+ 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.
-2.1.5 The Salt Field
+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 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.
+ 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.
- 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.
+ 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.
- 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.
+ 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.
-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 August 5, 2006 [Page 8]
+\f
+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
-Laurie, et al. Expires December 3, 2005 [Page 7]
-\f
-Internet-Draft nsec3 june 2005
+ 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.
+ NSEC3 RR's ownername. It is the unmodified binary hash value. It
+ does not include the name of the containing zone.
-2.1.7 The list of Type Bit Map(s) Field
+ 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 ownername.
+ 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.
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 9]
+\f
+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
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]
-\f
-Internet-Draft nsec3 june 2005
-
-
- appear in zone data. If encountered, they must be ignored upon
- reading.
+ 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
NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
be interpreted as zero octets.
-2.2 The NSEC3 RR Presentation Format
+3.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 Opt-In Flag Field is represented as an unsigned decimal integer.
+ The value is 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 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 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 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. Whitespace is allowed within the
- sequence.
+ insensitive base32 digits, without whitespace.
- 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.
+ The Type Bit Maps Field is represented as a sequence of RR type
-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 August 5, 2006 [Page 10]
+\f
+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.
-Laurie, et al. Expires December 3, 2005 [Page 9]
-\f
-Internet-Draft nsec3 june 2005
+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]
- an NSEC3 RR type and an RRSIG RR type.
-4. Calculation of the Hash
+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:
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]).
-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.
+6. Including NSEC3 RRs in a Zone
- 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.
+ Each ownername within the zone that owns authoritative RRsets MUST
- 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.
+Laurie, et al. Expires August 5, 2006 [Page 11]
+\f
+Internet-Draft nsec3 February 2006
- The following steps describe the proper construction of NSEC3
+ 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.
-Laurie, et al. Expires December 3, 2005 [Page 10]
-\f
-Internet-Draft nsec3 june 2005
+ 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.
- 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.
+ 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.
- 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.
+ 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.
-6. Special Considerations
-
- The following paragraphs clarify specific behaviour explain special
- considerations for implementations.
-6.1 Delegation Points
+7. Responding to NSEC3 Queries
- 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.
+ Since NSEC3 ownernames are not represented in the NSEC3 chain like
+ other zone ownernames, direct queries for NSEC3 ownernames present a
+ special case.
- 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 August 5, 2006 [Page 12]
+\f
+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.
-Laurie, et al. Expires December 3, 2005 [Page 11]
-\f
-Internet-Draft nsec3 june 2005
+ 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.
- 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.
+ Other cases where the QNAME equals an existing NSEC3 ownername may be
+ answered normally.
- 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.
+8. Special Considerations
- 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.
+ The following paragraphs clarify specific behaviour explain special
+ considerations for implementations.
-6.2 Proving Nonexistence
+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
- [RFC4035] describes the impact of wildcards on authenticated denial
- of existence.
+ 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,
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]
+Laurie, et al. Expires August 5, 2006 [Page 13]
\f
-Internet-Draft nsec3 june 2005
+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
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
+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 the dictionary doubles. The NSEC3 RR can use a
- maximum of 2040 bits of salt, multiplying the cost by 2^2040.
+ 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]
+\f
+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]
+\f
+Internet-Draft nsec3 February 2006
+
+
+ +--------------+------------+
+ | DSA Key Size | Iterations |
+ +--------------+------------+
+ | 1024 | 1,500 |
+ | 2048 | 5,000 |
+ +--------------+------------+
- 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.
+ 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.
- The salt SHOULD be changed every time the zone is resigned to prevent
- precomputation using a single salt.
+ 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.
-6.4 Hash Collision
+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
assessing possible damage in the event of an attack using hash
collisions.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 13]
-\f
-Internet-Draft nsec3 june 2005
-
-
-6.4.1 Avoiding Hash Collisions during generation
+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
- SHOULD be chosen and all hash values SHOULD be regenerated.
+ MUST be chosen and all hash values MUST 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
+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
+ 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.
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]
+\f
+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.
-6.4.3 Possible Hash Value Truncation Method
+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
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.
+ 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. 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]
-\f
-Internet-Draft nsec3 june 2005
-
+ 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
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
+ 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.
-7. Performance Considerations
+8.4.4. Server Response to a Run-time Collision
- 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.
+ 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]
+\f
+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
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.
+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.
-9. Security Considerations
+
+11. 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]
+Laurie, et al. Expires August 5, 2006 [Page 18]
\f
-Internet-Draft nsec3 june 2005
+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.
- 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.
+ 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
fantastically unlikely, and, in any case, DNSSEC already relies on
SHA-1 to not collide.
-10. References
+ 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.
-10.1 Normative References
+ 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.
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
+ 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.
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
+ 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
- [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.
+Laurie, et al. Expires August 5, 2006 [Page 19]
+\f
+Internet-Draft nsec3 February 2006
- [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.
+ within the span of an Opt-In NSEC3 record.
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
+ 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
-Laurie, et al. Expires December 3, 2005 [Page 16]
-\f
-Internet-Draft nsec3 june 2005
+ RCODE=NOERROR
+ Answer Section:
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
+ Authority Section:
+ DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
+ RRSIG DNSKEY
+ abcd... RRSIG NSEC3 ...
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
+ Additional Section:
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
+ 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.
-10.2 Informative References
+ 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.
- [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.
+ 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.
- [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.
+12. References
-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 August 5, 2006 [Page 20]
+\f
+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.
-Laurie, et al. Expires December 3, 2005 [Page 17]
+ [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]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- 7523 XC Enschede
- The Netherlands
+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.
- 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.
+ 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
m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
1SH5r/wfjuCg+g== )
3600 MX 1 xx.example.
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 22]
+\f
+Internet-Draft nsec3 February 2006
+
+
3600 RRSIG MX 5 1 3600 20050712112304 (
20050612112304 62699 example.
L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
ExXT48OGGdbfIme5
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 18]
-\f
-Internet-Draft nsec3 june 2005
-
-
) ; Key ID = 62699
3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
20050612112304 62699 example.
3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
766A6A4837206C )
3600 RRSIG DS 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 23]
+\f
+Internet-Draft nsec3 February 2006
+
+
20050612112304 62699 example.
QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
ZXW5S+1VjMZYzQ== )
3600 HINFO "KLH-10" "ITS"
3600 RRSIG HINFO 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 19]
-\f
-Internet-Draft nsec3 june 2005
-
-
20050612112304 62699 example.
AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
OwQBGbOegrW/Zw== )
jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
deadbeaf
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 24]
+\f
+Internet-Draft nsec3 February 2006
+
+
kcll7fqfnisuhfekckeeqnmbbd4maanu
NSEC3 RRSIG )
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
20050612112304 62699 example.
d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 20]
-\f
-Internet-Draft nsec3 june 2005
-
-
IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
TOLtc5jPrkL4zQ== )
n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
AkeTJu3J3auUiA== )
vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
deadbeaf
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 25]
+\f
+Internet-Draft nsec3 February 2006
+
+
wbyijvpnyj33pcpi3i44ecnibnaj7eiw
HINFO A AAAA NSEC3 RRSIG )
3600 RRSIG NSEC3 5 2 3600 20050712112304 (
xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
gQlgxEwhvQDEaQ== )
x.w.example. 3600 MX 1 xx.example.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 21]
-\f
-Internet-Draft nsec3 june 2005
-
-
3600 RRSIG MX 5 3 3600 20050712112304 (
20050612112304 62699 example.
s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
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]
+\f
+Internet-Draft nsec3 February 2006
+
+
20050612112304 62699 example.
rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
OcFlrPGPMm48/A== )
-
-
-Laurie, et al. Expires December 3, 2005 [Page 22]
-\f
-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
+B.1. answer
A successful query to an authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 23]
+Laurie, et al. Expires August 5, 2006 [Page 27]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=0
-Laurie, et al. Expires December 3, 2005 [Page 24]
+Laurie, et al. Expires August 5, 2006 [Page 28]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
The query returned an MX RRset for "x.w.example". The corresponding
falls between the signature inception and expiration dates, the
signature is authenticated.
-B.1.1 Authenticating the Example DNSKEY RRset
+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
-Laurie, et al. Expires December 3, 2005 [Page 25]
+Laurie, et al. Expires August 5, 2006 [Page 29]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
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
+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]
+Laurie, et al. Expires August 5, 2006 [Page 30]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=3
-Laurie, et al. Expires December 3, 2005 [Page 27]
+Laurie, et al. Expires August 5, 2006 [Page 31]
\f
-Internet-Draft nsec3 june 2005
+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 hasing the apex ownername (The SOA
+ 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.
+ 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
these hashed ownernames do not exists, since the names are within the
given intervals.
-B.3 No Data Error
+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]
+Laurie, et al. Expires August 5, 2006 [Page 32]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=0
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
+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]
+Laurie, et al. Expires August 5, 2006 [Page 33]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=0
proving a No Data Error. This example is solely mentioned to be
complete.
-B.4 Referral to Signed Zone
+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
-Laurie, et al. Expires December 3, 2005 [Page 30]
+Laurie, et al. Expires August 5, 2006 [Page 34]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR DO RCODE=0
all keys in the "a.example" DNSKEY RRset are considered
authenticated.
-B.5 Referral to Unsigned Zone using Opt-In
+B.5. Referral to Unsigned Zone using the Opt-In Flag
- 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
+ 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]
+
+Laurie, et al. Expires August 5, 2006 [Page 35]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR DO RCODE=0
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
+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
-Laurie, et al. Expires December 3, 2005 [Page 32]
+Laurie, et al. Expires August 5, 2006 [Page 36]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=0
-Laurie, et al. Expires December 3, 2005 [Page 33]
+Laurie, et al. Expires August 5, 2006 [Page 37]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
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
+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
-Laurie, et al. Expires December 3, 2005 [Page 34]
+Laurie, et al. Expires August 5, 2006 [Page 38]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=0
not exist and no wildcard applies. The negative reply is
authenticated by verifying both NSEC3 RRs.
-B.8 DS Child Zone No Data Error
+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]
+Laurie, et al. Expires August 5, 2006 [Page 39]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
;; Header: QR AA DO RCODE=0
-Laurie, et al. Expires December 3, 2005 [Page 36]
+Laurie, et al. Expires August 5, 2006 [Page 40]
+\f
+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]
\f
-Internet-Draft nsec3 june 2005
+Internet-Draft nsec3 February 2006
Intellectual Property Statement
Copyright Statement
- Copyright (C) The Internet Society (2005). This document is subject
+ 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.
-Laurie, et al. Expires December 3, 2005 [Page 37]
+Laurie, et al. Expires August 5, 2006 [Page 42]
\f
DNSOP O. Kolkman
Internet-Draft R. Gieben
Obsoletes: 2541 (if approved) NLnet Labs
-Expires: August 25, 2006 February 21, 2006
+Expires: September 7, 2006 March 6, 2006
DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-07.txt
+ draft-ietf-dnsop-dnssec-operational-practices-08.txt
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on August 25, 2006.
+ This Internet-Draft will expire on September 7, 2006.
Copyright Notice
-Kolkman & Gieben Expires August 25, 2006 [Page 1]
+Kolkman & Gieben Expires September 7, 2006 [Page 1]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ This document obsoletes RFC 2541, as it covers more operational
+ ground and gives more up to date requirements with respect to key
+ sizes and the new DNSSEC specification.
Table of Contents
3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6
3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6
3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7
- 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 7
+ 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 8
3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 8
+ 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9
3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 11
+ 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 12
4. Signature generation, Key Rollover and Related Policies . . . 12
4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
- 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 12
+ 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13
4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 14
- 4.2.1. Zone signing Key Rollovers . . . . . . . . . . . . . . 14
- 4.2.2. Key signing Key Rollovers . . . . . . . . . . . . . . 18
- 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 19
- 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 20
- 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 21
- 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 21
- 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 23
- 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 23
- 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 23
+ 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
+ 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19
+ 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 20
+ 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 21
+ 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 22
+ 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
+ 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
+ 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 24
+ 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 24
4.4.1. Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . 23
- 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 24
- 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 24
- 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 25
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 27
- Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 28
- Appendix B. Zone signing Key Rollover Howto . . . . . . . . . . . 29
- Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 29
- Appendix D. Document Details and Changes . . . . . . . . . . . . 31
- D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 31
- D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 31
- D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 31
- D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 32
- D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 32
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 2]
+ Considerations . . . . . . . . . . . . . . . . . . . . 24
+ 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 25
+ 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 25
+ 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 26
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
+ Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 29
+ Appendix B. Zone Signing Key Rollover Howto . . . . . . . . . . . 30
+ Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 31
+ Appendix D. Document Details and Changes . . . . . . . . . . . . 33
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 2]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
- D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 32
- D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 32
- D.8. draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 32
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
- Intellectual Property and Copyright Statements . . . . . . . . . . 34
-
-
+Internet-Draft DNSSEC Operational Practices March 2006
+ D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
+ D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
+ D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
+ D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
+ D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
+ D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
+ D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
+ D.8. draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
+ D.9. draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
+ Intellectual Property and Copyright Statements . . . . . . . . . . 36
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 3]
+Kolkman & Gieben Expires September 7, 2006 [Page 3]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
1. Introduction
+ This document describes how to run a DNSSEC (DNS SECure) enabled
+ environment. It is intended for operators who have knowledge of the
+ DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC. See
+ RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
+ newly introduced Resource Records and finally RFC 4035 [6] for the
+ protocol changes.
+
During workshops and early operational deployment tests, operators
and system administrators have gained experience about operating the
DNS with security extensions (DNSSEC). This document translates
Appendix C.
Since this is a document with operational suggestions and there are
- no protocol specifications, the RFC2119 [3] language does not apply.
+ no protocol specifications, the RFC 2119 [9] language does not apply.
- This document obsoletes RFC2541 [6].
+ This document obsoletes RFC 2541 [12].
1.1. The Use of the Term 'key'
It is assumed that the reader is familiar with the concept of
asymmetric keys on which DNSSEC is based (Public Key Cryptography
- [12]). Therefore, this document will use the term 'key' rather
+ [18]). Therefore, this document will use the term 'key' rather
loosely. Where it is written that 'a key is used to sign data' it is
- assumed that the reader understands that it is the private part of
- the key pair that is used for signing. It is also assumed that the
- reader understands that the public part of the key pair is published
- in the DNSKEY resource record and that it is the public part that is
- used in key exchanges.
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 4]
+Kolkman & Gieben Expires September 7, 2006 [Page 4]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ assumed that the reader understands that it is the private part of
+ the key pair that is used for signing. It is also assumed that the
+ reader understands that the public part of the key pair is published
+ in the DNSKEY resource record and that it is the public part that is
+ used in key exchanges.
+
1.2. Time Definitions
In this document we will be using a number of time related terms.
replaced with a new signature (made with the same key). This
replacement takes place by publishing the relevant RRSIG in the
master zone file.
- After one stopped publishing an RRSIG in a zone it may take a
+ After one stops publishing an RRSIG in a zone it may take a
while before the RRSIG has expired from caches and has actually
been removed from the DNS.
o "Key effectivity period"
the key.
The key effectivity period can span multiple signature validity
periods.
- o "Maximum/Minimum Zone TTL"
+ o "Maximum/Minimum Zone Time to Live (TTL)"
The maximum or minimum value of the TTLs from the complete set
of RRs in a zone. Note that the minimum TTL is not the same as
- the MINIMUM field in the SOA RR. See [5] for more information.
+ the MINIMUM field in the SOA RR. See [11] for more
+ information.
2. Keeping the Chain of Trust Intact
Maintaining a valid chain of trust is important because broken chains
- of trust will result in data being marked as Bogus (as defined in [2]
+ of trust will result in data being marked as Bogus (as defined in [4]
section 5), which may cause entire (sub)domains to become invisible
to verifying clients. The administrators of secured zones have to
realize that their zone is, to verifying clients, part of a chain of
trust.
As mentioned in the introduction, the procedures herein are intended
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 5]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
to ensure that maintenance of zones, such as re-signing or key
rollovers, will be transparent to the verifying clients on the
Internet.
Administrators of secured zones will have to keep in mind that data
published on an authoritative primary server will not be immediately
seen by verifying clients; it may take some time for the data to be
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
transferred to other secondary authoritative nameservers and clients
may be fetching data from caching non-authoritative servers. In this
light it is good to note that the time for a zone transfer from
- master to slave is negligible when using NOTIFY and IXFR, increasing
- by reliance on AXFR, and more if you rely on the SOA timing
- parameters for zone refresh.
+ master to slave is negligible when using NOTIFY [8] and IXFR [7],
+ increasing by reliance on AXFR, and more if you rely on the SOA
+ timing parameters for zone refresh.
For the verifying clients it is important that data from secured
zones can be used to build chains of trust regardless of whether the
The DNSSEC validation protocol does not distinguish between different
types of DNSKEYs. All DNSKEYs can be used during the validation. In
practice operators use Key Signing and Zone Signing Keys and use the
- so-called (Secure Entry Point) SEP [1] flag to distinguish between
+ so-called (Secure Entry Point) SEP [3] flag to distinguish between
them during operations. The dynamics and considerations are
discussed below.
To make zone re-signing and key rollover procedures easier to
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 6]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
implement, it is possible to use one or more keys as Key Signing Keys
(KSK). These keys will only sign the apex DNSKEY RRSet in a zone.
Other keys can be used to sign all the RRSets in a zone and are
that KSKs are the subset of keys that are used for key exchanges with
the parent and potentially for configuration as trusted anchors - the
SEP keys. In this document we assume a one-to-one mapping between
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
3.1.1. Motivations for the KSK and ZSK Separation
verifying resolvers that have the particular key configured as secure
entry points. Hence, the key effectivity period of these keys can
and should be made much longer. Although, given a long enough key,
- the Key Effectivity Period can be on the order of years we suggest
- planning for a key effectivity of the order of a few months so that a
- key rollover remains an operational routine.
-3.1.2. KSKs for High Level Zones
- Higher level zones are generally more sensitive than lower level
+Kolkman & Gieben Expires September 7, 2006 [Page 7]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
-Kolkman & Gieben Expires August 25, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
+ the Key Effectivity Period can be on the order of years we suggest
+ planning for a key effectivity of the order of a few months so that a
+ key rollover remains an operational routine.
+3.1.2. KSKs for High Level Zones
+ Higher level zones are generally more sensitive than lower level
zones. Anyone controlling or breaking the security of a zone thereby
obtains authority over all of its sub domains (except in the case of
resolvers that have locally configured the public key of a sub
The strongest algorithms used with the longest keys are still of no
use if an adversary can guess enough to lower the size of the likely
key space so that it can be exhaustively searched. Technical
- suggestions for the generation of random keys will be found in
- RFC4086 [9]. One should carefully assess if the random number
+ suggestions for the generation of random keys will be found in RFC
+ 4086 [15]. One should carefully assess if the random number
generator used during key generation adheres to these suggestions.
Keys with a long effectivity period are particularly sensitive as
from the network via an air gap or, at a minimum, high level secure
hardware.
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 8]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
3.3. Key Effectivity Period
For various reasons keys in DNSSEC need to be changed once in a
espionage, or cryptanalysis. Furthermore when key rollovers are too
rare an event, they will not become part of the operational habit and
there is risk that nobody on-site will remember the procedure for
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
rollover when the need is there.
From a purely operational perspective a reasonable key effectivity
them after 12 months. An intended key effectivity period of a month
is reasonable for Zone Signing Keys.
- For a key sizes that matches these effectivity periods see
- Section 3.5.
+ For key sizes that matches these effectivity periods see Section 3.5.
As argued in Section 3.1.2 securely updating trust anchors will be
extremely difficult. On the other hand the "operational habit"
RSA has been developed in an open and transparent manner. As the
patent on RSA expired in 2000, its use is now also free.
- DSA has been developed by NIST. The creation of signatures is
- roughly done at the same speed as with RSA, but is 10 to 40 times as
- slow for verification [12].
+ DSA has been developed by NIST. The creation of signatures takes
+ roughly the same time as with RSA, but is 10 to 40 times as slow for
+ verification [18].
We suggest the use of RSA/SHA-1 as the preferred algorithm for the
key. The current known attacks on RSA can be defeated by making your
key longer. As the MD5 hashing algorithm is showing (theoretical)
cracks, we recommend the usage of SHA-1.
- At the time of publication it is known that the SHA-1 hash has
- cryptanalysis issues. There is work in progress on addressing these
- issues. We recommend to use public key algorithms based on hashes
- stronger than SHA-1, e.g. SHA-256, as soon as these algorithms are
- available in protocol specifications (See [14] and [15] ) and
- implementations.
-
-Kolkman & Gieben Expires August 25, 2006 [Page 9]
+Kolkman & Gieben Expires September 7, 2006 [Page 9]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ At the time of publication it is known that the SHA-1 hash has
+ cryptanalysis issues. There is work in progress on addressing these
+ issues. We recommend the use of public key algorithms based on
+ hashes stronger than SHA-1, e.g. SHA-256, as soon as these
+ algorithms are available in protocol specifications (See [20] and
+ [21] ) and implementations.
+
3.5. Key Sizes
When choosing key sizes, zone administrators will need to take into
account how long a key will be used, how much data will be signed
- during the key publication period (See Section 8.10 of [12]) and,
+ during the key publication period (See Section 8.10 of [18]) and,
optionally, how large the key size of the parent is. As the chain of
- trust really is "a chain", it does not make much sense in making one
- of the keys in the chain several times larger then the others. As
+ trust really is "a chain", there is not much sense in making one of
+ the keys in the chain several times larger then the others. As
always, it's the weakest link that defines the strength of the entire
chain. Also see Section 3.1.1 for a discussion of how keys serving
different roles (ZSK v. KSK) may need different key sizes.
- Generating a key of the correct size is a difficult problem, RFC3766
- [8] tries to deal with that problem. Paragraph 1 of that RFC states:
+ Generating a key of the correct size is a difficult problem, RFC 3766
+ [14] tries to deal with that problem. The first part of the
+ selection procedure in Section 1 of the RFC states:
1. Determine the attack resistance necessary to satisfy the
security requirements of the application. Do this by
for system security. The 90 bit number should be increased
by about 2/3 bit/year, or about 96 bits in 2005.
- [8] goes on to explain how this number "n" can be used to calculate
+ [14] goes on to explain how this number "n" can be used to calculate
the key sizes in public key cryptography. This culminated in the
table given below (slightly modified for our purpose):
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 10]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+-------------+-----------+--------------+
| System | | |
| requirement | Symmetric | RSA or DSA |
+-------------+-----------+--------------+
The key sizes given are rather large. This is because these keys are
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
resilient against a trillionaire attacker. Assuming this rich
attacker will not attack your key and that the key is rolled over
once a year, we come to the following recommendations about KSK
Note that nobody can see into the future, and that these key sizes
are only provided here as a guide. Further information can be found
- in [11] and Section 7.5 of [12]. It should be noted though that [11]
+ in [17] and Section 7.5 of [18]. It should be noted though that [17]
is already considered overly optimistic about what key sizes are
considered safe.
validate and create RRSIGs increases with larger keys, so don't
needlessly double your key sizes.
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 11]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
3.6. Private Key Storage
It is recommended that, where possible, zone private keys and the
zone by adding RRSIG and NSEC RRs. Then the augmented file can be
transferred.
- When relying on dynamic update to manage a signed zone [4], be aware
+ When relying on dynamic update to manage a signed zone [10], be aware
that at least one private key of the zone will have to reside on the
master server. This key is only as secure as the amount of exposure
the server receives to unknown clients and the security of the host.
set, although its name appears in the SOA RRs MNAME field. The
nameservers in the NS RR set are able to receive zone updates through
NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism. This
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
approach is known as the "hidden master" setup.
The ideal situation is to have a one way information flow to the
network. Operators are advised to take security measures to shield
unauthorized access to the master copy.
- For dynamically updated secured zones [4] both the master copy and
+ For dynamically updated secured zones [10] both the master copy and
the private key that is used to update signatures on updated RRs will
need to be on-line.
Without DNSSEC all times in DNS are relative. The SOA fields
REFRESH, RETRY and EXPIRATION are timers used to determine the time
elapsed after a slave server synchronized with a master server. The
- Time to Live (TTL) value and the SOA RR minimum TTL parameter [5] are
- used to determine how long a forwarder should cache data after it has
- been fetched from an authoritative server. By using a signature
+ Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 12]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ are used to determine how long a forwarder should cache data after it
+ has been fetched from an authoritative server. By using a signature
validity period, DNSSEC introduces the notion of an absolute time in
the DNS. Signatures in DNSSEC have an expiration date after which
the signature is marked as invalid and the signed data is to be
If the TTL would be of similar order as the signature validity
period, then all RRSets fetched during the validity period
would be cached until the signature expiration time. Section
- 7.1 of [2] suggests that "the resolver may use the time
+ 7.1 of [4] suggests that "the resolver may use the time
remaining before expiration of the signature validity period of
a signed RRSet as an upper bound for the TTL". As a result
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
query load on authoritative servers would peak at signature
expiration time, as this is also the time at which records
simultaneously expire from caches.
caches. This in turn may lead to peaks in the load on
authoritative servers.
o We suggest the minimum zone TTL to be long enough to both fetch
- and verifying all the RRs in the trust chain. In workshop
- environments it has been demonstrated [13] that a low TTL (under 5
+ and verify all the RRs in the trust chain. In workshop
+ environments it has been demonstrated [19] that a low TTL (under 5
to 10 minutes) caused disruptions because of the following two
problems:
1. During validation, some data may expire before the
2. Frequent verification causes load on recursive nameservers.
Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
caching. The TTL on those should be relatively long.
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 13]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
o Slave servers will need to be able to fetch newly signed zones
well before the RRSIGs in the zone served by the slave server pass
their signature expiration time.
the signatures expire well before the SOA expiration timer
counts down to zero. It is not possible to completely prevent
this from happening by tweaking the SOA parameters.
-
-
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
However, the effects can be minimized where the SOA expiration
time is equal or shorter than the signature validity period.
The consequence of an authoritative server not being able to
rollovers -- or supercessions, as they are sometimes called -- are a
fact of life when using DNSSEC. Zone administrators who are in the
process of rolling their keys have to take into account that data
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 14]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
published in previous versions of their zone still lives in caches.
When deploying DNSSEC, this becomes an important consideration;
ignoring data that may be in caches may lead to loss of service for
signed with a new key against an old key that lives in a local cache,
also resulting in data being marked Bogus.
-4.2.1. Zone signing Key Rollovers
+4.2.1. Zone Signing Key Rollovers
For zone signing key rollovers there are two ways to make sure that
during the rollover data still cached can be verified with the new
key sets or newly generated signatures can be verified with the keys
still in caches. One schema, described in Section 4.2.1.2, uses
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 14]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
double signatures; the other uses key pre-publication
(Section 4.2.1.1). The pros, cons and recommendations are described
in Section 4.2.1.3.
as is the case with the double signature ZSK rollover. A small
"HOWTO" for this kind of rollover can be found in Appendix B.
+ Pre-publish Key Rollover involves four stages as follows:
+
initial new DNSKEY new RRSIGs DNSKEY removal
SOA0 SOA1 SOA2 SOA3
RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 15]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
initial: Initial version of the zone: DNSKEY 1 is the key signing
key. DNSKEY 10 is used to sign all the data of the zone, the zone
signing key.
previous version of the zone to expire from old caches i.e. the
time it takes for this zone to propagate to all authoritative
servers plus the Maximum Zone TTL value of any of the data in the
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 15]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
previous version of the zone.
DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now
only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
(II)":
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 16]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
initial new RRSIGs new DNSKEY
SOA0 SOA1 SOA2
RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
- new RRSIGs (II) new DNSKEY (II)
+ new RRSIGs (II) new DNSKEY (II)
SOA3 SOA4
RRSIG12(SOA3) RRSIG12(SOA4)
RRSIG12(DNSKEY) RRSIG12(DNSKEY)
+ Pre-Publish Key Rollover, showing two rollovers.
+
Note that the key introduced in the "new DNSKEY" phase is not used
for production yet; the private key can thus be stored in a
physically secure manner and does not need to be 'fetched' every time
a zone needs to be signed.
-4.2.1.2. Double Signature Zone signing Key Rollover
+4.2.1.2. Double Signature Zone Signing Key Rollover
This section shows how to perform a ZSK key rollover using the double
zone data signature scheme, aptly named "double sig rollover".
During the "new DNSKEY" stage the new version of the zone file will
need to propagate to all authoritative servers and the data that
+ exists in (distant) caches will need to expire, requiring at least
+ the maximum Zone TTL.
+
+
+
+
-Kolkman & Gieben Expires August 25, 2006 [Page 16]
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 17]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
- exists in (distant) caches will need to expire, requiring at least
- the maximum Zone TTL.
+ Double Signature Zone Signing Key Rollover involves three stages as
+ follows:
initial new DNSKEY DNSKEY removal
new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
introduced into the key set and all the data in the zone is signed
with DNSKEY 10 and DNSKEY 11. The rollover period will need to
- exist until all data from version 0 of the zone has expired from
- remote caches. This will take at least the maximum Zone TTL of
- version 0 of the zone.
+ continue until all data from version 0 of the zone has expired
+ from remote caches. This will take at least the maximum Zone TTL
+ of version 0 of the zone.
DNSKEY removal: DNSKEY 10 is removed from the zone. All the
signatures from DNSKEY 10 are removed from the zone. The key set,
now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-Kolkman & Gieben Expires August 25, 2006 [Page 17]
+Kolkman & Gieben Expires September 7, 2006 [Page 18]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
4.2.1.3. Pros and Cons of the Schemes
have very big zones. An advantage is that it only requires three
steps.
-4.2.2. Key signing Key Rollovers
+4.2.2. Key Signing Key Rollovers
For the rollover of a key signing key the same considerations as for
the rollover of a zone signing key apply. However we can use a
RRSIG2 (DNSKEY) -------->
RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
- initial: Initial version of the zone. The parental DS points to
- DNSKEY1. Before the rollover starts the child will have to verify
- what the TTL is of the DS RR that points to DNSKEY1 - it is needed
- during the rollover and we refer to the value as TTL_DS.
+ Stages of Deployment for Key Signing Key Rollover.
+
-Kolkman & Gieben Expires August 25, 2006 [Page 18]
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 19]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ initial: Initial version of the zone. The parental DS points to
+ DNSKEY1. Before the rollover starts the child will have to verify
+ what the TTL is of the DS RR that points to DNSKEY1 - it is needed
+ during the rollover and we refer to the value as TTL_DS.
new DNSKEY: During the "new DNSKEY" phase the zone administrator
generates a second KSK, DNSKEY2. The key is provided to the
parent and the child will have to wait until a new DS RR has been
As the KSK is used to validate the key set and because the KSK is not
changed during a ZSK rollover, a cache is able to validate the new
- key set of the zone. The pre-publish method would work for a KSK
- rollover. The records that are to be pre-published are the parental
- DS RRs. The pre-publish method has some drawbacks for KSKs. We
- first describe the rollover scheme and then indicate these drawbacks.
-
-
-
-
-
+ key set of the zone. The pre-publish method would also work for a
+ KSK rollover. The records that are to be pre-published are the
+ parental DS RRs. The pre-publish method has some drawbacks for KSKs.
+ We first describe the rollover scheme and then indicate these
+ drawbacks.
-Kolkman & Gieben Expires August 25, 2006 [Page 19]
+Kolkman & Gieben Expires September 7, 2006 [Page 20]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
initial new DS new DNSKEY DS/DNSKEY removal
RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+ Stages of Deployment for a Pre-publish Key Signing Key rollover.
+
When the child zone wants to roll it notifies the parent during the
"new DS" phase and submits the new key (or the corresponding DS) to
the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1
o A KSK rollover needs interaction between parent and child. Data
exchange is needed to provide the new keys to the parent,
consequently, this data must be authenticated and integrity must
- be guaranteed in order to avoid attacks on the rollover.
-
-Kolkman & Gieben Expires August 25, 2006 [Page 20]
+Kolkman & Gieben Expires September 7, 2006 [Page 21]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ be guaranteed in order to avoid attacks on the rollover.
+
4.3. Planning for Emergency Key Rollover
This section deals with preparation for a possible key compromise.
-- however the chain of trust of this particular key is broken).
Note that an attacker's zone still uses the compromised KSK and the
- presence of a parental DS would cause the data in this zone to appear
- as valid. Removing the compromised key would cause the attacker's
-Kolkman & Gieben Expires August 25, 2006 [Page 21]
+Kolkman & Gieben Expires September 7, 2006 [Page 22]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ presence of a parental DS would cause the data in this zone to appear
+ as valid. Removing the compromised key would cause the attacker's
zone to appear as valid and the child's zone as Bogus. Therefore we
advise not to remove the KSK before the parent has a DS to a new KSK
in place.
An additional danger of a key compromise is that the compromised key
could be used to facilitate a legitimate DNSKEY/DS rollover and/or
nameserver changes at the parent. When that happens the domain may
- be in dispute. An authenticated out of band and secure notify
+ be in dispute. An authenticated out-of-band and secure notify
mechanism to contact a parent is needed in this case.
Note that this is only a problem when the DNSKEY and or DS records
In the method that causes the child zone to appear as 'Bogus' to
validating resolvers, the child zone replaces the current KSK with a
new one and resigns the key set. Next it sends the DS of the new key
- to the parent. Only after the parent has placed the new DS in the
- zone, the child's chain of trust is repaired.
-Kolkman & Gieben Expires August 25, 2006 [Page 22]
+Kolkman & Gieben Expires September 7, 2006 [Page 23]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ to the parent. Only after the parent has placed the new DS in the
+ zone, the child's chain of trust is repaired.
+
An alternative method of breaking the chain of trust is by removing
the DS RRs from the parent zone altogether. As a result the child
zone would become insecure.
be authenticated e.g. by using digital signatures.
End-users faced with the task of updating an anchored key should
- always validate the new key. New keys should be authenticated out of
- band, for example, looking them up on an SSL secured announcement
+ always validate the new key. New keys should be authenticated out-
+ of-band, for example, looking them up on an SSL secured announcement
website.
4.4. Parental Policies
authorization mechanisms used for the exchange of delegation
information between parent and child. I.e. there is no implicit need
in DNSSEC to make the authentication process stronger than it was in
- DNS.
-
- Using the DNS itself as the source for the actual DNSKEY material,
-Kolkman & Gieben Expires August 25, 2006 [Page 23]
+Kolkman & Gieben Expires September 7, 2006 [Page 24]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
- with an off-band check on the validity of the DNSKEY, has the benefit
- that it reduces the chances of user error. A DNSKEY query tool can
- make use of the SEP bit [1] to select the proper key from a DNSSEC
- key set; thereby reducing the chance that the wrong DNSKEY is sent.
- It can validate the self-signature over a key; thereby verifying the
- ownership of the private key material. Fetching the DNSKEY from the
- DNS ensures that the chain of trust remains intact once the parent
- publishes the DS RR indicating the child is secure.
+ DNS.
- Note: the off-band verification is still needed when the key-material
- is fetched via the DNS. The parent can never be sure whether the
- DNSKEY RRs have been spoofed or not.
+ Using the DNS itself as the source for the actual DNSKEY material,
+ with an out-of-band check on the validity of the DNSKEY, has the
+ benefit that it reduces the chances of user error. A DNSKEY query
+ tool can make use of the SEP bit [3] to select the proper key from a
+ DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
+ sent. It can validate the self-signature over a key; thereby
+ verifying the ownership of the private key material. Fetching the
+ DNSKEY from the DNS ensures that the chain of trust remains intact
+ once the parent publishes the DS RR indicating the child is secure.
+
+ Note: the out-of-band verification is still needed when the key-
+ material is fetched via the DNS. The parent can never be sure
+ whether the DNSKEY RRs have been spoofed or not.
4.4.2. Storing Keys or Hashes?
registrant and registry; Will the child zone administrator be able to
upload DS RRs with unknown hash algorithms or does the interface only
allow DNSKEYs? In the registry-registrar model one can use the
- DNSSEC EPP protocol extension [10] which allows transfer of DS RRs
+ DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
and optionally DNSKEY RRs.
4.4.3. Security Lameness
child's zone may be marked as "Bogus" by verifying DNS clients.
As part of a comprehensive delegation check the parent could, at key
- exchange time, verify that the child's key is actually configured in
- the DNS. However if a parent does not understand the hashing
- algorithm used by child the parental checks are limited to only
-Kolkman & Gieben Expires August 25, 2006 [Page 24]
+Kolkman & Gieben Expires September 7, 2006 [Page 25]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ exchange time, verify that the child's key is actually configured in
+ the DNS. However if a parent does not understand the hashing
+ algorithm used by child the parental checks are limited to only
comparing the key id.
Child zones should be very careful removing DNSKEY material,
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 25]
+Kolkman & Gieben Expires September 7, 2006 [Page 26]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
6. Security Considerations
Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
- Some material in this document has been shamelessly copied from
- RFC2541 [6] by Donald Eastlake.
+ Some material in this document has been copied from RFC 2541 [12].
Mike StJohns designed the key exchange between parent and child
mentioned in the last paragraph of Section 4.2.2
8.1. Normative References
- [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
- (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
- RFC 3757, May 2004.
+ [1] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
-Kolkman & Gieben Expires August 25, 2006 [Page 26]
+Kolkman & Gieben Expires September 7, 2006 [Page 27]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
+ (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+ RFC 3757, May 2004.
+
+ [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
+ [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
8.2. Informative References
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ August 1996.
+
+ [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
+ (DNS NOTIFY)", RFC 1996, August 1996.
+
+ [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
- [4] Eastlake, D., "Secure Domain Name System Dynamic Update",
+ [10] Eastlake, D., "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
- [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+ [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
RFC 2308, March 1998.
- [6] Eastlake, D., "DNS Security Operational Considerations",
+ [12] Eastlake, D., "DNS Security Operational Considerations",
RFC 2541, March 1999.
- [7] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+ [13] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
- [8] Orman, H. and P. Hoffman, "Determining Strengths For Public
+ [14] Orman, H. and P. Hoffman, "Determining Strengths For Public
Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
April 2004.
- [9] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ [15] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
- [10] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
- Mapping for the Extensible Provisioning Protocol (EPP)",
- draft-hollenbeck-epp-secdns-07 (work in progress), March 2005.
+ [16] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
+ Mapping for the Extensible Provisioning Protocol (EPP)",
+ RFC 4310, December 2005.
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 28]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
- [11] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+ [17] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", The Journal of Cryptology 14 (255-293), 2001.
- [12] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
- Source Code in C", 1996.
+ [18] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
+ Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
+ (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
+ 1996.
- [13] Rose, S., "NIST DNSSEC workshop notes", June 2001.
+ [19] Rose, S., "NIST DNSSEC workshop notes", June 2001.
- [14] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
+ [20] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
(work in progress), January 2006.
- [15] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+ [21] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
(work in progress), January 2006.
-
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 27]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
Appendix A. Terminology
In this document there is some jargon used that is defined in other
Anchored Key: A DNSKEY configured in resolvers around the globe.
This key is hard to update, hence the term anchored.
- Bogus: Also see Section 5 of [2]. An RRSet in DNSSEC is marked
+ Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked
"Bogus" when a signature of a RRSet does not validate against a
DNSKEY.
Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
exclusively for signing the apex key set. The fact that a key is
a KSK is only relevant to the signing tool.
Key size: The term 'key size' can be substituted by 'modulus size'
- throughout the document. It is mathematical more correct to use
+ throughout the document. It is mathematically more correct to use
modulus size, but as this is a document directed at operators we
feel more at ease with the term key size.
Private and Public Keys: DNSSEC secures the DNS through the use of
public key cryptography. Public key cryptography is based on the
- existence of two (mathematical related) keys, a public key and a
+ existence of two (mathematically related) keys, a public key and a
private key. The public keys are published in the DNS by use of
the DNSKEY Resource Record (DNSKEY RR). Private keys should
remain private.
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 29]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
Key Rollover: A key rollover (also called key supercession in some
environments) is the act of replacing one key pair by another at
the end of a key effectivity period.
Secure Entry Point key or SEP Key: A KSK that has a parental DS
record pointing to it or is configured as a trust anchor.
Although not required by the protocol we recommend that the SEP
- flag [1] is set on these keys.
+ flag [3] is set on these keys.
Self-signature: This is only applies to signatures over DNSKEYs; a
signature made with DNSKEY x, over DNSKEY x is called a self-
signature. Note: without further information self-signatures
- convey no trust, they are usefull to check the authenticity of the
+ convey no trust, they are useful to check the authenticity of the
DNSKEY, i.e. they can be used as a hash.
Singing the Zone File: The term used for the event where an
administrator joyfully signs its zone file while producing melodic
signs the Resource Record sets in a zone. A signer may be
configured to sign only parts of the zone e.g. only those RRSets
for which existing signatures are about to expire.
-
-
-
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 28]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
used for signing all data in a zone. The fact that a key is a ZSK
is only relevant to the signing tool.
and publishing it on the primary authoritative server.
-Appendix B. Zone signing Key Rollover Howto
+Appendix B. Zone Signing Key Rollover Howto
Using the pre-published signature scheme and the most conservative
method to assure oneself that data does not live in caches, here
Step 2: Then start using the key that was marked as "published" to
sign your data i.e. mark it as "active". Stop using the key that
was marked as "active", mark it as "rolled".
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 30]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
Step 3: It is safe to engage in a new rollover (Step 1) after at
least one "signature validity period".
to just "A".
Signature notation: Signatures are denoted as RRSIGx(RRSet), which
means that RRSet is signed with DNSKEYx.
+ Zone representation: Using the above notation we have simplified the
+ representation of a signed zone by leaving out all unnecessary
+ details such as the names and by representing all data by "SOAx"
+ SOA representation: SOAs are represented as SOAx, where x is the
+ serial number.
+ Using this notation the following signed zone:
+
+
+
+
+
+
+
+
+
-Kolkman & Gieben Expires August 25, 2006 [Page 29]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
- Zone representation: Using the above notation we have simplified the
- representation of a signed zone by leaving out all unnecessary
- details such as the names and by representing all data by "SOAx"
- SOA representation: SOAs are represented as SOAx, where x is the
- serial number.
- Using this notation the following signed zone:
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 31]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
example.net. 86400 IN SOA ns.example.net. bert.example.net. (
20130407213204 14 example.net.
SO5epiJei19AjXoUpFnQ ... )
86400 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0... )
- ; key id = 14
+ EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
86400 DNSKEY 257 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU... )
- ; key id = 15
+ gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
20130422213204 14 example.net.
J4zCe8QX4tXVGjV4e1r9... )
is reduced to the following representation:
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 30]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
SOA2006022100
RRSIG14(SOA2006022100)
-
DNSKEY14
DNSKEY15
RRSIG15(KEY)
The rest of the zone data has the same signature as the SOA record,
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 32]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
i.e a RRSIG created with DNSKEY 14.
Added Automatic rollover requirements from I-D.ietf-dnsop-key-
rollover-requirements.
-
-
-
-
-
-Kolkman & Gieben Expires August 25, 2006 [Page 31]
-\f
-Internet-Draft DNSSEC Operational Practices February 2006
-
-
D.4. draft-ietf-dnsop-dnssec-operational-practices-03
Added the definition of Key effectivity period and used that term
Modified the order of the sections, based on a suggestion by Rip
Loomis.
- Included parts from RFC2541 [6]. Most of its ground was already
- covered. This document obsoletes RFC2541 [6]. Section 3.1.2
- deserves some review as it in contrast to RFC2541 does _not_ give
+ Included parts from RFC 2541 [12]. Most of its ground was already
+ covered. This document obsoletes RFC 2541 [12]. Section 3.1.2
+ deserves some review as it in contrast to RFC 2541 does _not_ give
recomendations about root-zone keys.
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 33]
+\f
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
added a paragraph to Section 4.4.4
D.5. draft-ietf-dnsop-dnssec-operational-practices-04
SHA-1/SHA-256 remarks added
+D.9. draft-ietf-dnsop-dnssec-operational-practices-08
+
+ IESG comments applied. Added headers and some captions to the tables
+ and applied all the nits.
+
+ IESG DISCUSS comments applied
+
+
+
+
+
+
+
-Kolkman & Gieben Expires August 25, 2006 [Page 32]
+Kolkman & Gieben Expires September 7, 2006 [Page 34]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
Authors' Addresses
-Kolkman & Gieben Expires August 25, 2006 [Page 33]
+Kolkman & Gieben Expires September 7, 2006 [Page 35]
\f
-Internet-Draft DNSSEC Operational Practices February 2006
+Internet-Draft DNSSEC Operational Practices March 2006
Intellectual Property Statement
-Kolkman & Gieben Expires August 25, 2006 [Page 34]
+Kolkman & Gieben Expires September 7, 2006 [Page 36]
\f
projects / thirdparty / bind9.git / commitdiff
