Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
dbec0f1bd9 |
@@ -1,755 +0,0 @@
|
||||
|
||||
|
||||
Network Working Group B. Laurie
|
||||
Internet-Draft Nominet
|
||||
Expires: March 2, 2005 R. Loomis
|
||||
SAIC
|
||||
September 2004
|
||||
|
||||
|
||||
|
||||
Requirements related to DNSSEC Signed Proof of Non-Existence
|
||||
draft-ietf-dnsext-signed-nonexistence-requirements-01
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
|
||||
This document is an Internet-Draft and is subject to all provisions
|
||||
of section 3 of RFC 3667. By submitting this Internet-Draft, each
|
||||
author represents that any applicable patent or other IPR claims of
|
||||
which he or she is aware have been or will be disclosed, and any of
|
||||
which he or she become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as
|
||||
Internet-Drafts.
|
||||
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
|
||||
This Internet-Draft will expire on March 2, 2005.
|
||||
|
||||
|
||||
Copyright Notice
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004).
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
|
||||
DNSSEC-bis uses the NSEC record to provide authenticated denial of
|
||||
existence of RRsets. NSEC also has the side-effect of permitting
|
||||
zone enumeration, even if zone transfers have been forbidden.
|
||||
Because some see this as a problem, this document has been assembled
|
||||
to detail the possible requirements for denial of existence A/K/A
|
||||
signed proof of non-existence.
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 1]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4
|
||||
5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4
|
||||
6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4
|
||||
7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5
|
||||
10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6
|
||||
11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6
|
||||
12. Non-overlap of denial records with possible zone records . . 7
|
||||
13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7
|
||||
14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8
|
||||
15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8
|
||||
16. Minimisation of Client Complexity . . . . . . . . . . . . . 8
|
||||
17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8
|
||||
19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8
|
||||
21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9
|
||||
22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9
|
||||
23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9
|
||||
24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9
|
||||
25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
28. Requirements notation . . . . . . . . . . . . . . . . . . . 9
|
||||
29. Security Considerations . . . . . . . . . . . . . . . . . . 10
|
||||
30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
30.1 Normative References . . . . . . . . . . . . . . . . . . . 10
|
||||
30.2 Informative References . . . . . . . . . . . . . . . . . . 10
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
|
||||
Intellectual Property and Copyright Statements . . . . . . . 11
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 2]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
|
||||
NSEC records allow trivial enumeration of zones - a situation that
|
||||
has existed for several years but which has recently been raised as a
|
||||
significant concern for DNSSECbis deployment in several zones.
|
||||
Alternate proposals have been made that make zone enumeration more
|
||||
difficult, and some previous proposals to modify DNSSEC had related
|
||||
requirements/desirements that are relevant to the discussion. In
|
||||
addition the original designs for NSEC/NXT records were based on
|
||||
working group discussions and the choices made were not always
|
||||
documented with context and requirements-- so some of those choices
|
||||
may need to be restated as requirements. Overall, the working group
|
||||
needs to better understand the requirements for denial of existence
|
||||
(and certain other requirements related to DNSSECbis deployment) in
|
||||
order to evaluate the proposals that may replace NSEC.
|
||||
|
||||
|
||||
In the remainder of this document, "NSEC++" is used as shorthand for
|
||||
"a denial of existence proof that will replace NSEC". "NSECbis" has
|
||||
also been used as shorthand for this, but we avoid that usage since
|
||||
NSECbis will not be part of DNSSECbis and therefore there might be
|
||||
some confusion.
|
||||
|
||||
|
||||
2. Non-purposes
|
||||
|
||||
|
||||
This document does not currently document the reasons why zone
|
||||
enumeration might be "bad" from a privacy, security, business, or
|
||||
other perspective--except insofar as those reasons result in
|
||||
requirements. Once the list of requirements is complete and vaguely
|
||||
coherent, the trade-offs (reducing zone enumeration will have X cost,
|
||||
while providing Y benefit) may be revisited. The editors of this
|
||||
compendium received inputs on the potential reasons why zone
|
||||
enumeration is bad (and there was significant discussion on the
|
||||
DNSEXT WG mailing list) but that information fell outside the scope
|
||||
of this document.
|
||||
|
||||
|
||||
Note also that this document does not assume that NSEC *must* be
|
||||
replaced with NSEC++, if the requirements can be met through other
|
||||
methods (e.g., "white lies" with the current NSEC). As is stated
|
||||
above, this document is focused on requirements collection and
|
||||
(ideally) prioritization rather than on the actual implementation.
|
||||
|
||||
|
||||
3. Zone Enumeration
|
||||
|
||||
|
||||
Authenticated denial should not permit trivial zone enumeration.
|
||||
|
||||
|
||||
Additional discussion: NSEC (and NXT before it) provide a linked
|
||||
list that could be "walked" to trivially enumerate all the signed
|
||||
records in a zone. This requirement is primarily (though not
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 3]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
exclusively) important for zones that either are delegation-only/
|
||||
-mostly or do not have reverse lookup (PTR) records configured, since
|
||||
enterprises that have PTR records for all A records have already
|
||||
provided a similar capability to enumerate the contents of DNS zones.
|
||||
|
||||
|
||||
Contributor: various
|
||||
|
||||
|
||||
4. Zone Enumeration II
|
||||
|
||||
|
||||
Zone enumeration should be at least as difficult as it would be to
|
||||
effect a dictionary attack using simple DNS queries to do the same in
|
||||
an unsecured zone.
|
||||
|
||||
|
||||
(Editor comment: it is not clear how to measure difficulty in this
|
||||
case. Some examples could be monetary cost, bandwidth, processing
|
||||
power or some combination of these. It has also been suggested that
|
||||
the requirement is that the graph of difficulty of enumeration vs.
|
||||
the fraction of the zone enumerated should be approximately the same
|
||||
shape in the two cases)
|
||||
|
||||
|
||||
Contributor: Nominet
|
||||
|
||||
|
||||
5. Zone Enumeration III
|
||||
|
||||
|
||||
Enumeration of a zone with random contents should computationally
|
||||
infeasible.
|
||||
|
||||
|
||||
Editor comment: this is proposed as a way of evaluating the
|
||||
effectiveness of a proposal rather than as a requirement anyone would
|
||||
actually have in practice.
|
||||
|
||||
|
||||
Contributor: Alex Bligh
|
||||
|
||||
|
||||
6. Exposure of Contents
|
||||
|
||||
|
||||
NSEC++ should not expose any of the contents of the zone (apart from
|
||||
the NSEC++ records themselves, of course).
|
||||
|
||||
|
||||
Editor comment: this is a weaker requirement than prevention of
|
||||
enumeration, but certainly any zone that satisfied this requirement
|
||||
would also satisfy the trivial prevention of enumeration requirement.
|
||||
|
||||
|
||||
Contributor: Ed Lewis
|
||||
|
||||
|
||||
7. Zone Size
|
||||
|
||||
|
||||
Requirement: NSEC++ should make it possible to take precautions
|
||||
against trivial zone size estimates. Since not all zone owners care
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 4]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
about others estimation of the size of a zone, it is not always
|
||||
necessary to prohibit trivial estimation of the size of the zone but
|
||||
NSEC++ should allow such measures.
|
||||
|
||||
|
||||
Additional Discussion: Even with proposals based on obfuscating names
|
||||
with hashes it is trivial to give very good estimates of the number
|
||||
of domains in a certain zone. Just send 10 random queries and look
|
||||
at the range between the two hash values returned in each NSEC++. As
|
||||
hash output can be assumed to follow a rectangular random
|
||||
distribution, using the mean difference between the two values, you
|
||||
can estimate the total number of records. It is probably sufficient
|
||||
to look at even one NSEC++, since the two hash values should follow a
|
||||
(I believe) Poisson distribution.
|
||||
|
||||
|
||||
The concern is motivated by some wording remembered from NSEC, which
|
||||
stated that NSEC MUST only be present for existing owner names in the
|
||||
zone, and MUST NOT be present for non-existing owner names. If
|
||||
similar wording were carried over to NSEC++, introducing bogus owner
|
||||
names in the hash chain (an otherwise simple solution to guard
|
||||
against trivial estimates of zone size) wouldn't be allowed.
|
||||
|
||||
|
||||
One simple attempt at solving this is to describe in the
|
||||
specifications how zone signer tools can add a number of random
|
||||
"junk" records.
|
||||
|
||||
|
||||
Editor's comment: it is interesting that obfuscating names might
|
||||
actually make it easier to estimate zone size.
|
||||
|
||||
|
||||
Contributor: Simon Josefsson.
|
||||
|
||||
|
||||
8. Single Method
|
||||
|
||||
|
||||
Requirement: A single NSEC++ method must be able to carry both
|
||||
old-style denial (i.e. plain labels) and whatever the new style
|
||||
looks like. Having two separate denial methods could result in
|
||||
cornercases where one method can deny the other and vice versa.
|
||||
|
||||
|
||||
Additional discussion: This requirement can help -bis folks to a
|
||||
smooth upgrade to -ter. First they'd change the method while the
|
||||
content is the same, then they can change content of the method.
|
||||
|
||||
|
||||
Contributor: Roy Arends.
|
||||
|
||||
|
||||
9. Empty Non-terminals
|
||||
|
||||
|
||||
Requirement: Empty-non-terminals (ENT) should remain empty. In
|
||||
other words, adding NSEC++ records to an existing DNS structure
|
||||
should not cause the creation of NSEC++ records (or related records)
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 5]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
at points that are otherwise ENT.
|
||||
|
||||
|
||||
Additional discussion: Currently NSEC complies with ENT requirement:
|
||||
b.example.com NSEC a.c.example.com implies the existence of an ENT
|
||||
with ownername c.example.com. NSEC2 breaks that requirement, since
|
||||
the ownername is entirely hashed causing the structure to disappear.
|
||||
This is why EXIST was introduced. But EXIST causes ENT to be
|
||||
non-empty-terminals. Next to the dissappearance of ENT, it causes
|
||||
(some) overhead since an EXIST record needs a SIG, NSEC2 and
|
||||
SIG(NSEC2). DNSNR honours this requirement by hashing individual
|
||||
labels instead of ownernames. However this causes very long labels.
|
||||
Truncation is a measure against very long ownernames, but that is
|
||||
controversial. There is a fair discussion of the validity of
|
||||
truncation in the DNSNR draft, but that hasn't got proper review yet.
|
||||
|
||||
|
||||
Contributor: Roy Arends.
|
||||
|
||||
|
||||
(Editor comment: it is not clear to us that an EXIST record needs an
|
||||
NSEC2 record, since it is a special purpose record only used for
|
||||
denial of existence)
|
||||
|
||||
|
||||
10. Prevention of Precomputed Dictionary Attacks
|
||||
|
||||
|
||||
Requirement: NSEC++ needs to provide a method to reduce the
|
||||
effectiveness of precomputed dictionary attacks.
|
||||
|
||||
|
||||
Additional Discussion: Salt is a measure against dictionary attacks.
|
||||
There are other possible measures (such as iterating hashes in
|
||||
NSEC2). The salt needs to be communicated in every response, since
|
||||
it is needed in every verification. Some have suggested to move the
|
||||
salt to a special record instead of the denial record. I think this
|
||||
is not wise. Response size has more priority over zone size. An
|
||||
extra record causes a larger response than a larger existing record.
|
||||
|
||||
|
||||
Contributor: Roy Arends.
|
||||
|
||||
|
||||
(Editor comment: the current version of NSEC2 also has the salt in
|
||||
every NSEC2 record)
|
||||
|
||||
|
||||
11. DNSSEC-Adoption and Zone-Growth Relationship
|
||||
|
||||
|
||||
Background: Currently with NSEC, when a delegation centric zone
|
||||
deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
|
||||
when the DNSSEC-adoption rate of the subzones remains low--because
|
||||
each delegation point creates at least one NSEC record and
|
||||
corresponding signature in the parent even if the child is not
|
||||
signed.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 6]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
Requirements: A delegation-only (or delegation-mostly) zone that is
|
||||
signed but which has no signed child zones should initially need only
|
||||
to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
|
||||
minimal set of NSEC++ records to cover zone contents. Further,
|
||||
during the transition of a delegation-only zone from 0% signed
|
||||
children to 100% signed children, the growth in the delegation-only
|
||||
zone should be roughly proportional to the percentage of signed child
|
||||
zones.
|
||||
|
||||
|
||||
Additional Discussion: This is why DNSNR has the Authoritative Only
|
||||
bit. This is similar to opt-in for delegations only. This (bit) is
|
||||
currently the only method to help delegation-centric zone cope with
|
||||
zone-growth due to DNSSEC adoption. As an example, A delegation only
|
||||
zone which deploys DNSSEC with the help of this bit, needs to add
|
||||
SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
|
||||
more than that.
|
||||
|
||||
|
||||
Contributor: Roy Arends.
|
||||
|
||||
|
||||
12. Non-overlap of denial records with possible zone records
|
||||
|
||||
|
||||
Requirement: NSEC++ records should in some way be differentiated
|
||||
from regular zone records, so that there is no possibility that a
|
||||
record in the zone could be duplicated by a non-existence proof
|
||||
(NSEC++) record.
|
||||
|
||||
|
||||
Additional discussion: This requirement is derived from a discussion
|
||||
on the DNSEXT mailing list related to copyrights and domain names.
|
||||
As was outlined there, one solution is to put NSEC++ records in a
|
||||
separate namespace, e.g.: $ORIGIN co.uk.
|
||||
873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
|
||||
delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
|
||||
; for amazon.co.uk.
|
||||
|
||||
|
||||
Contributor: various
|
||||
|
||||
|
||||
(Editor comment: One of us still does not see why a conflict
|
||||
matters. Even if there is an apparent conflict or overlap, the
|
||||
"conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
|
||||
other name _never_ appears in NSEC2 records.)
|
||||
|
||||
|
||||
13. Exposure of Private Keys
|
||||
|
||||
|
||||
Private keys associated with the public keys in the DNS should be
|
||||
exposed as little as possible. It is highly undesirable for private
|
||||
keys to be distributed to nameservers, or to otherwise be available
|
||||
in the run-time environment of nameservers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 7]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
Contributors: Nominet, Olaf Kolkman, Ed Lewis
|
||||
|
||||
|
||||
14. Minimisation of Zone Signing Cost
|
||||
|
||||
|
||||
The additional cost of creating an NSEC++ signed zone should not
|
||||
significantly exceed the cost of creating an ordinary signed zone.
|
||||
|
||||
|
||||
Contributor: Nominet
|
||||
|
||||
|
||||
15. Minimisation of Asymmetry
|
||||
|
||||
|
||||
Nameservers should have to do as little additional work as necessary.
|
||||
More precisely, it is desirable for any increase in cost incurred by
|
||||
the nameservers to be offset by a proportionate increase in cost to
|
||||
DNS `clients', e.g. stub and/or `full-service' resolvers.
|
||||
|
||||
|
||||
Contributor: Nominet
|
||||
|
||||
|
||||
16. Minimisation of Client Complexity
|
||||
|
||||
|
||||
Caching, wildcards, CNAMEs, DNAMEs should continue to work without
|
||||
adding too much complexity at the client side.
|
||||
|
||||
|
||||
Contributor: Olaf Kolkman
|
||||
|
||||
|
||||
17. Completeness
|
||||
|
||||
|
||||
A proof of nonexistence should be possible for all nonexistent data
|
||||
in the zone.
|
||||
|
||||
|
||||
Contributor: Olaf Kolkman
|
||||
|
||||
|
||||
18. Purity of Namespace
|
||||
|
||||
|
||||
The name space should not be muddied with fake names or data sets.
|
||||
|
||||
|
||||
Contributor: Ed Lewis
|
||||
|
||||
|
||||
19. Replay Attacks
|
||||
|
||||
|
||||
NSEC++ should not allow a replay to be used to deny existence of an
|
||||
RR that actually exists.
|
||||
|
||||
|
||||
Contributor: Ed Lewis
|
||||
|
||||
|
||||
20. Compatibility with NSEC
|
||||
|
||||
|
||||
NSEC++ should not introduce changes incompatible with NSEC.
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 8]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
Contributor: Ed Lewis
|
||||
|
||||
|
||||
21. Compatibility with NSEC II
|
||||
|
||||
|
||||
NSEC++ should differ from NSEC in a way that is transparent to the
|
||||
resolver or validator.
|
||||
|
||||
|
||||
Contributor: Ed Lewis
|
||||
|
||||
|
||||
22. Compatibility with NSEC III
|
||||
|
||||
|
||||
NSEC++ should differ from NSEC as little as possible whilst achieving
|
||||
other requirements.
|
||||
|
||||
|
||||
Contributor: Alex Bligh
|
||||
|
||||
|
||||
23. Coexistence with NSEC
|
||||
|
||||
|
||||
NSEC++ should be optional, allowing NSEC to be used instead.
|
||||
|
||||
|
||||
Contributor: Ed Lewis, Alex Bligh
|
||||
|
||||
|
||||
24. Coexistence with NSEC II
|
||||
|
||||
|
||||
NSEC++ should not impose extra work on those content with NSEC.
|
||||
|
||||
|
||||
Contributor: Ed Lewis
|
||||
|
||||
|
||||
25. Protocol Design
|
||||
|
||||
|
||||
A good security protocol would allow signing the nonexistence of some
|
||||
selected names without revealing anything about other names.
|
||||
|
||||
|
||||
Contributor: Dan Bernstein
|
||||
|
||||
|
||||
26. Process
|
||||
|
||||
|
||||
Clearly not all of these requirements can be met. Therefore the next
|
||||
phase of this document will be to either prioritise them or narrow
|
||||
them down to a non-contradictory set, which should then allow us to
|
||||
judge proposals on the basis of their fit.
|
||||
|
||||
|
||||
27. Acknowledgements
|
||||
|
||||
|
||||
28. Requirements notation
|
||||
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 9]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
|
||||
29. Security Considerations
|
||||
|
||||
|
||||
There are currently no security considerations called out in this
|
||||
draft. There will be security considerations in the choice of which
|
||||
requirements will be implemented, but there are no specific security
|
||||
requirements during the requirements collection process.
|
||||
|
||||
|
||||
30. References
|
||||
|
||||
|
||||
30.1 Normative References
|
||||
|
||||
|
||||
[dnssecbis-protocol]
|
||||
"DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
|
||||
Month 2004.
|
||||
|
||||
|
||||
30.2 Informative References
|
||||
|
||||
|
||||
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
|
||||
3", BCP 9, RFC 2026, October 1996.
|
||||
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
|
||||
Procedures", BCP 25, RFC 2418, September 1998.
|
||||
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
|
||||
Ben Laurie
|
||||
Nominet
|
||||
17 Perryn Road
|
||||
London W3 7LR
|
||||
England
|
||||
|
||||
|
||||
Phone: +44 (20) 8735 0686
|
||||
EMail: ben@algroup.co.uk
|
||||
|
||||
|
||||
|
||||
Rip Loomis
|
||||
Science Applications International Corporation
|
||||
7125 Columbia Gateway Drive, Suite 300
|
||||
Columbia, MD 21046
|
||||
US
|
||||
|
||||
|
||||
EMail: gilbert.r.loomis@saic.com
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 10]
|
||||
Internet-Draft signed-nonexistence-requirements September 2004
|
||||
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Laurie & Loomis Expires March 2, 2005 [Page 11]
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -1,451 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group O. Kolkman
|
||||
Request for Comments: 3757 RIPE NCC
|
||||
Updates: 3755, 2535 J. Schlyter
|
||||
Category: Standards Track NIC-SE
|
||||
E. Lewis
|
||||
ARIN
|
||||
April 2004
|
||||
|
||||
|
||||
Domain Name System KEY (DNSKEY) Resource Record (RR)
|
||||
Secure Entry Point (SEP) Flag
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
With the Delegation Signer (DS) resource record (RR), the concept of
|
||||
a public key acting as a secure entry point (SEP) has been
|
||||
introduced. During exchanges of public keys with the parent there is
|
||||
a need to differentiate SEP keys from other public keys in the Domain
|
||||
Name System KEY (DNSKEY) resource record set. A flag bit in the
|
||||
DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
|
||||
The flag bit is intended to assist in operational procedures to
|
||||
correctly generate DS resource records, or to indicate what DNSKEYs
|
||||
are intended for static configuration. The flag bit is not to be
|
||||
used in the DNS verification protocol. This document updates RFC
|
||||
2535 and RFC 3755.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 1]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||||
2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
|
||||
3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
|
||||
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
|
||||
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
|
||||
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
|
||||
7. Internationalization Considerations. . . . . . . . . . . . . . 6
|
||||
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
|
||||
9.2. Informative References . . . . . . . . . . . . . . . . . 6
|
||||
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
|
||||
|
||||
1. Introduction
|
||||
|
||||
"All keys are equal but some keys are more equal than others" [6].
|
||||
|
||||
With the definition of the Delegation Signer Resource Record (DS RR)
|
||||
[5], it has become important to differentiate between the keys in the
|
||||
DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
|
||||
other keys in the DNSKEY RR set. We refer to these public keys as
|
||||
Secure Entry Point (SEP) keys. A SEP key either used to generate a
|
||||
DS RR or is distributed to resolvers that use the key as the root of
|
||||
a trusted subtree [3].
|
||||
|
||||
In early deployment tests, the use of two (kinds of) key pairs for
|
||||
each zone has been prevalent. For one kind of key pair the private
|
||||
key is used to sign just the zone's DNSKEY resource record (RR) set.
|
||||
Its public key is intended to be referenced by a DS RR at the parent
|
||||
or configured statically in a resolver. The private key of the other
|
||||
kind of key pair is used to sign the rest of the zone's data sets.
|
||||
The former key pair is called a key-signing key (KSK) and the latter
|
||||
is called a zone-signing key (ZSK). In practice there have been
|
||||
usually one of each kind of key pair, but there will be multiples of
|
||||
each at times.
|
||||
|
||||
It should be noted that division of keys pairs into KSK's and ZSK's
|
||||
is not mandatory in any definition of DNSSEC, not even with the
|
||||
introduction of the DS RR. But, in testing, this distinction has
|
||||
been helpful when designing key roll over (key super-cession)
|
||||
schemes. Given that the distinction has proven helpful, the labels
|
||||
KSK and ZSK have begun to stick.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 2]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
There is a need to differentiate the public keys for the key pairs
|
||||
that are used for key signing from keys that are not used key signing
|
||||
(KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
|
||||
be sent for generating DS RRs, which DNSKEYs are to be distributed to
|
||||
resolvers, and which keys are fed to the signer application at the
|
||||
appropriate time.
|
||||
|
||||
In other words, the SEP bit provides an in-band method to communicate
|
||||
a DNSKEY RR's intended use to third parties. As an example we
|
||||
present 3 use cases in which the bit is useful:
|
||||
|
||||
The parent is a registry, the parent and the child use secured DNS
|
||||
queries and responses, with a preexisting trust-relation, or plain
|
||||
DNS over a secured channel to exchange the child's DNSKEY RR sets.
|
||||
Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
|
||||
bit can be used to isolate the DNSKEYs for which a DS RR needs to
|
||||
be created.
|
||||
|
||||
An administrator has configured a DNSKEY as root for a trusted
|
||||
subtree into security aware resolver. Using a special purpose
|
||||
tool that queries for the KEY RRs from that domain's apex, the
|
||||
administrator will be able to notice the roll over of the trusted
|
||||
anchor by a change of the subset of KEY RRs with the DS flag set.
|
||||
|
||||
A signer might use the SEP bit on the public key to determine
|
||||
which private key to use to exclusively sign the DNSKEY RRset and
|
||||
which private key to use to sign the other RRsets in the zone.
|
||||
|
||||
As demonstrated in the above examples it is important to be able to
|
||||
differentiate the SEP keys from the other keys in a DNSKEY RR set in
|
||||
the flow between signer and (parental) key-collector and in the flow
|
||||
between the signer and the resolver configuration. The SEP flag is
|
||||
to be of no interest to the flow between the verifier and the
|
||||
authoritative data store.
|
||||
|
||||
The reason for the term "SEP" is a result of the observation that the
|
||||
distinction between KSK and ZSK key pairs is made by the signer, a
|
||||
key pair could be used as both a KSK and a ZSK at the same time. To
|
||||
be clear, the term SEP was coined to lessen the confusion caused by
|
||||
the overlap. (Once this label was applied, it had the side effect of
|
||||
removing the temptation to have both a KSK flag bit and a ZSK flag
|
||||
bit.)
|
||||
|
||||
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
|
||||
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
|
||||
interpreted as described in BCP 14, RFC 2119 [1].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 3]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
2. The Secure Entry Point (SEP) Flag
|
||||
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| flags |S| protocol | algorithm |
|
||||
| |E| | |
|
||||
| |P| | |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| /
|
||||
/ public key /
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
DNSKEY RR Format
|
||||
This document assigns the 15th bit in the flags field as the secure
|
||||
entry point (SEP) bit. If the bit is set to 1 the key is intended to
|
||||
be used as secure entry point key. One SHOULD NOT assign special
|
||||
meaning to the key if the bit is set to 0. Operators can recognize
|
||||
the secure entry point key by the even or odd-ness of the decimal
|
||||
representation of the flag field.
|
||||
|
||||
3. DNSSEC Protocol Changes
|
||||
|
||||
The bit MUST NOT be used during the resolving and verification
|
||||
process. The SEP flag is only used to provide a hint about the
|
||||
different administrative properties of the key and therefore the use
|
||||
of the SEP flag does not change the DNS resolution protocol or the
|
||||
resolution process.
|
||||
|
||||
4. Operational Guidelines
|
||||
|
||||
The SEP bit is set by the key-pair-generator and MAY be used by the
|
||||
zone signer to decide whether the public part of the key pair is to
|
||||
be prepared for input to a DS RR generation function. The SEP bit is
|
||||
recommended to be set (to 1) whenever the public key of the key pair
|
||||
will be distributed to the parent zone to build the authentication
|
||||
chain or if the public key is to be distributed for static
|
||||
configuration in verifiers.
|
||||
|
||||
When a key pair is created, the operator needs to indicate whether
|
||||
the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
|
||||
the data that is used to compute the 'key tag field' in the SIG RR,
|
||||
changing the SEP bit will change the identity of the key within DNS.
|
||||
In other words, once a key is used to generate signatures, the
|
||||
setting of the SEP bit is to remain constant. If not, a verifier
|
||||
will not be able to find the relevant KEY RR.
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 4]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
When signing a zone, it is intended that the key(s) with the SEP bit
|
||||
set (if such keys exist) are used to sign the KEY RR set of the zone.
|
||||
The same key can be used to sign the rest of the zone data too. It
|
||||
is conceivable that not all keys with a SEP bit set will sign the
|
||||
DNSKEY RR set, such keys might be pending retirement or not yet in
|
||||
use.
|
||||
|
||||
When verifying a RR set, the SEP bit is not intended to play a role.
|
||||
How the key is used by the verifier is not intended to be a
|
||||
consideration at key creation time.
|
||||
|
||||
Although the SEP flag provides a hint on which public key is to be
|
||||
used as trusted root, administrators can choose to ignore the fact
|
||||
that a DNSKEY has its SEP bit set or not when configuring a trusted
|
||||
root for their resolvers.
|
||||
|
||||
Using the SEP flag a key roll over can be automated. The parent can
|
||||
use an existing trust relation to verify DNSKEY RR sets in which a
|
||||
new DNSKEY RR with the SEP flag appears.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
As stated in Section 3 the flag is not to be used in the resolution
|
||||
protocol or to determine the security status of a key. The flag is
|
||||
to be used for administrative purposes only.
|
||||
|
||||
No trust in a key should be inferred from this flag - trust MUST be
|
||||
inferred from an existing chain of trust or an out-of-band exchange.
|
||||
|
||||
Since this flag might be used for automating public key exchanges, we
|
||||
think the following consideration is in place.
|
||||
|
||||
Automated mechanisms for roll over of the DS RR might be vulnerable
|
||||
to a class of replay attacks. This might happen after a public key
|
||||
exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
|
||||
SEP flag set, is sent to the parent. The parent verifies the DNSKEY
|
||||
RR set with the existing trust relation and creates the new DS RR
|
||||
from the DNSKEY RR that the current DS RR is not pointing to. This
|
||||
key exchange might be replayed. Parents are encouraged to implement
|
||||
a replay defense. A simple defense can be based on a registry of
|
||||
keys that have been used to generate DS RRs during the most recent
|
||||
roll over. These same considerations apply to entities that
|
||||
configure keys in resolvers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 5]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
|
||||
Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
|
||||
|
||||
7. Internationalization Considerations
|
||||
|
||||
Although SEP is a popular acronym in many different languages, there
|
||||
are no internationalization considerations.
|
||||
|
||||
8. Acknowledgments
|
||||
|
||||
The ideas documented in this document are inspired by communications
|
||||
we had with numerous people and ideas published by other folk. Among
|
||||
others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
|
||||
Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
|
||||
have contributed ideas and provided feedback.
|
||||
|
||||
This document saw the light during a workshop on DNSSEC operations
|
||||
hosted by USC/ISI in August 2002.
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[2] Eastlake, D., "Domain Name System Security Extensions", RFC
|
||||
2535, March 1999.
|
||||
|
||||
[3] Lewis, E., "DNS Security Extension Clarification on Zone
|
||||
Status", RFC 3090, March 2001.
|
||||
|
||||
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
|
||||
(DS)", RFC 3755, April 2004.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
|
||||
RFC 3658, December 2003.
|
||||
|
||||
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
|
||||
Story", ISBN 0151002177 (50th anniversary edition), April 1996.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 6]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
10. Authors' Addresses
|
||||
|
||||
Olaf M. Kolkman
|
||||
RIPE NCC
|
||||
Singel 256
|
||||
Amsterdam 1016 AB
|
||||
NL
|
||||
|
||||
Phone: +31 20 535 4444
|
||||
EMail: olaf@ripe.net
|
||||
URI: http://www.ripe.net/
|
||||
|
||||
|
||||
Jakob Schlyter
|
||||
NIC-SE
|
||||
Box 5774
|
||||
SE-114 87 Stockholm
|
||||
Sweden
|
||||
|
||||
EMail: jakob@nic.se
|
||||
URI: http://www.nic.se/
|
||||
|
||||
|
||||
Edward P. Lewis
|
||||
ARIN
|
||||
3635 Concorde Parkway Suite 200
|
||||
Chantilly, VA 20151
|
||||
US
|
||||
|
||||
Phone: +1 703 227 9854
|
||||
EMail: edlewis@arin.net
|
||||
URI: http://www.arin.net/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 7]
|
||||
|
||||
RFC 3757 DNSKEY RR SEP Flag April 2004
|
||||
|
||||
|
||||
11. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2004). 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.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
|
||||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
|
||||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed
|
||||
to pertain to the implementation or use of the technology
|
||||
described in this document or the extent to which any license
|
||||
under such rights might or might not be available; nor does it
|
||||
represent that it has made any independent effort to identify any
|
||||
such rights. Information on the procedures with respect to
|
||||
rights in RFC documents can be found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use
|
||||
of such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository
|
||||
at http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention
|
||||
any copyrights, patents or patent applications, or other
|
||||
proprietary rights that may cover technology that may be required
|
||||
to implement this standard. Please address the information to the
|
||||
IETF at ietf-ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kolkman, et al. Standard Track [Page 8]
|
||||
|
||||
@@ -1,283 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group A. Durand
|
||||
Request for Comments: 3901 SUN Microsystems, Inc.
|
||||
BCP: 91 J. Ihren
|
||||
Category: Best Current Practice Autonomica
|
||||
September 2004
|
||||
|
||||
|
||||
DNS IPv6 Transport Operational Guidelines
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document specifies an Internet Best Current Practices for the
|
||||
Internet Community, and requests discussion and suggestions for
|
||||
improvements. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2004).
|
||||
|
||||
Abstract
|
||||
|
||||
This memo provides guidelines and Best Current Practice for operating
|
||||
DNS in a world where queries and responses are carried in a mixed
|
||||
environment of IPv4 and IPv6 networks.
|
||||
|
||||
1. Introduction to the Problem of Name Space Fragmentation:
|
||||
following the referral chain
|
||||
|
||||
A resolver that tries to look up a name starts out at the root, and
|
||||
follows referrals until it is referred to a name server that is
|
||||
authoritative for the name. If somewhere down the chain of referrals
|
||||
it is referred to a name server that is only accessible over a
|
||||
transport which the resolver cannot use, the resolver is unable to
|
||||
finish the task.
|
||||
|
||||
When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
|
||||
only a matter of time until this starts to happen. The complete DNS
|
||||
hierarchy then starts to fragment into a graph where authoritative
|
||||
name servers for certain nodes are only accessible over a certain
|
||||
transport. The concern is that a resolver using only a particular
|
||||
version of IP and querying information about another node using the
|
||||
same version of IP can not do it because somewhere in the chain of
|
||||
servers accessed during the resolution process, one or more of them
|
||||
will only be accessible with the other version of IP.
|
||||
|
||||
With all DNS data only available over IPv4 transport everything is
|
||||
simple. IPv4 resolvers can use the intended mechanism of following
|
||||
referrals from the root and down while IPv6 resolvers have to work
|
||||
|
||||
|
||||
|
||||
Durand & Ihren Best Current Practice [Page 1]
|
||||
|
||||
RFC 3901 DNS IPv6 Transport Guidelines September 2004
|
||||
|
||||
|
||||
through a "translator", i.e., they have to use a recursive name
|
||||
server on a so-called "dual stack" host as a "forwarder" since they
|
||||
cannot access the DNS data directly.
|
||||
|
||||
With all DNS data only available over IPv6 transport everything would
|
||||
be equally simple, with the exception of IPv4 recursive name servers
|
||||
having to switch to a forwarding configuration.
|
||||
|
||||
However, the second situation will not arise in the foreseeable
|
||||
future. Instead, the transition will be from IPv4 only to a mixture
|
||||
of IPv4 and IPv6, with three categories of DNS data depending on
|
||||
whether the information is available only over IPv4 transport, only
|
||||
over IPv6 or both.
|
||||
|
||||
Having DNS data available on both transports is the best situation.
|
||||
The major question is how to ensure that it becomes the norm as
|
||||
quickly as possible. However, while it is obvious that some DNS data
|
||||
will only be available over v4 transport for a long time it is also
|
||||
obvious that it is important to avoid fragmenting the name space
|
||||
available to IPv4 only hosts. For example, during transition it is
|
||||
not acceptable to break the name space that we presently have
|
||||
available for IPv4-only hosts.
|
||||
|
||||
2. Terminology
|
||||
|
||||
The phrase "IPv4 name server" indicates a name server available over
|
||||
IPv4 transport. It does not imply anything about what DNS [1,2] data
|
||||
is served. Likewise, "IPv6 [4,5,6] name server" indicates a name
|
||||
server available over IPv6 transport. The phrase "dual-stack name
|
||||
server" indicates a name server that is actually configured to run
|
||||
both protocols, IPv4 and IPv6, and not merely a server running on a
|
||||
system capable of running both but actually configured to run only
|
||||
one.
|
||||
|
||||
3. Policy Based Avoidance of Name Space Fragmentation
|
||||
|
||||
Today there are only a few DNS "zones" on the public Internet that
|
||||
are available over IPv6 transport, and most of them can be regarded
|
||||
as "experimental". However, as soon as the root and top level
|
||||
domains are available over IPv6 transport, it is reasonable to expect
|
||||
that it will become more common to have zones served by IPv6 servers.
|
||||
|
||||
Having those zones served only by IPv6-only name server would not be
|
||||
a good development, since this will fragment the previously
|
||||
unfragmented IPv4 name space and there are strong reasons to find a
|
||||
mechanism to avoid it.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Durand & Ihren Best Current Practice [Page 2]
|
||||
|
||||
RFC 3901 DNS IPv6 Transport Guidelines September 2004
|
||||
|
||||
|
||||
The recommended approach to maintain name space continuity is to use
|
||||
administrative policies, as described in the next section.
|
||||
|
||||
4. DNS IPv6 Transport recommended Guidelines
|
||||
|
||||
In order to preserve name space continuity, the following
|
||||
administrative policies are recommended:
|
||||
|
||||
- every recursive name server SHOULD be either IPv4-only or dual
|
||||
stack,
|
||||
|
||||
This rules out IPv6-only recursive servers. However, one might
|
||||
design configurations where a chain of IPv6-only name server
|
||||
forward queries to a set of dual stack recursive name server
|
||||
actually performing those recursive queries.
|
||||
|
||||
- every DNS zone SHOULD be served by at least one IPv4-reachable
|
||||
authoritative name server.
|
||||
|
||||
This rules out DNS zones served only by IPv6-only authoritative
|
||||
name servers.
|
||||
|
||||
Note: zone validation processes SHOULD ensure that there is at least
|
||||
one IPv4 address record available for the name servers of any child
|
||||
delegations within the zone.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
The guidelines described in this memo introduce no new security
|
||||
considerations into the DNS protocol or associated operational
|
||||
scenarios.
|
||||
|
||||
6. Acknowledgment
|
||||
|
||||
This document is the result of many conversations that happened in
|
||||
the DNS community at IETF and elsewhere since 2001. During that
|
||||
period of time, a number of Internet drafts have been published to
|
||||
clarify various aspects of the issues at stake. This document
|
||||
focuses on the conclusion of those discussions.
|
||||
|
||||
The authors would like to acknowledge the role of Pekka Savola in his
|
||||
thorough review of the document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Durand & Ihren Best Current Practice [Page 3]
|
||||
|
||||
RFC 3901 DNS IPv6 Transport Guidelines September 2004
|
||||
|
||||
|
||||
7. 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] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
|
||||
9, RFC 2026, October 1996.
|
||||
|
||||
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
|
||||
Specification", RFC 2460, December 1998.
|
||||
|
||||
[5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
|
||||
Addressing Architecture", RFC 3513, April 2003.
|
||||
|
||||
[6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
|
||||
Extensions to Support IP Version 6", RFC 3596, October 2003.
|
||||
|
||||
8. Authors' Addresses
|
||||
|
||||
Alain Durand
|
||||
SUN Microsystems, Inc
|
||||
17 Network circle UMPK17-202
|
||||
Menlo Park, CA, 94025
|
||||
USA
|
||||
|
||||
EMail: Alain.Durand@sun.com
|
||||
|
||||
|
||||
Johan Ihren
|
||||
Autonomica
|
||||
Bellmansgatan 30
|
||||
SE-118 47 Stockholm
|
||||
Sweden
|
||||
|
||||
EMail: johani@autonomica.se
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Durand & Ihren Best Current Practice [Page 4]
|
||||
|
||||
RFC 3901 DNS IPv6 Transport Guidelines September 2004
|
||||
|
||||
|
||||
9. Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2004).
|
||||
|
||||
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.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
|
||||
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
|
||||
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the IETF's procedures with respect to rights in IETF Documents can
|
||||
be found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at ietf-
|
||||
ipr@ietf.org.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Durand & Ihren Best Current Practice [Page 5]
|
||||
|
||||
Reference in New Issue
Block a user