Compare commits
10 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
725b35e59c | ||
|
|
e27a76aad5 | ||
|
|
42783087f5 | ||
|
8a0af354df | ||
|
|
118d241075 | ||
|
|
634ba650ab | ||
|
8a01e8aa04 | ||
|
|
1a76f45e1c | ||
|
|
0ac645e2ac | ||
|
6710007f47 |
2
CHANGES
2
CHANGES
@@ -1,3 +1,5 @@
|
||||
--- 9.3.5 released ---
|
||||
|
||||
--- 9.3.5rc2 released ---
|
||||
|
||||
2338. [bug] check_ds() could be called with a non DS rdataset.
|
||||
|
||||
10595
doc/arm/Bv9ARM.pdf
10595
doc/arm/Bv9ARM.pdf
File diff suppressed because one or more lines are too long
@@ -1,840 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSEXT D. Blacka
|
||||
Internet-Draft VeriSign, Inc.
|
||||
Intended status: Standards Track April 7, 2006
|
||||
Expires: October 9, 2006
|
||||
|
||||
|
||||
DNSSEC Experiments
|
||||
draft-ietf-dnsext-dnssec-experiments-03
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on October 9, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 1]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a methodology for deploying alternate, non-
|
||||
backwards-compatible, DNSSEC methodologies in an experimental fashion
|
||||
without disrupting the deployment of standard DNSSEC.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
|
||||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8
|
||||
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
|
||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . 13
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 15
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 2]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
1. Definitions and Terminology
|
||||
|
||||
Throughout this document, familiarity with the DNS system (RFC 1035
|
||||
[5]) and the DNS security extensions ([2], [3], and [4] is assumed.
|
||||
|
||||
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 [1].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 3]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
2. Overview
|
||||
|
||||
Historically, experimentation with DNSSEC alternatives has been a
|
||||
problematic endeavor. There has typically been a desire to both
|
||||
introduce non-backwards-compatible changes to DNSSEC and to try these
|
||||
changes on real zones in the public DNS. This creates a problem when
|
||||
the change to DNSSEC would make all or part of the zone using those
|
||||
changes appear bogus (bad) or otherwise broken to existing security-
|
||||
aware resolvers.
|
||||
|
||||
This document describes a standard methodology for setting up DNSSEC
|
||||
experiments. This methodology addresses the issue of co-existence
|
||||
with standard DNSSEC and DNS by using unknown algorithm identifiers
|
||||
to hide the experimental DNSSEC protocol modifications from standard
|
||||
security-aware resolvers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 4]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
3. Experiments
|
||||
|
||||
When discussing DNSSEC experiments, it is necessary to classify these
|
||||
experiments into two broad categories:
|
||||
|
||||
Backwards-Compatible: describes experimental changes that, while not
|
||||
strictly adhering to the DNSSEC standard, are nonetheless
|
||||
interoperable with clients and servers that do implement the
|
||||
DNSSEC standard.
|
||||
|
||||
Non-Backwards-Compatible: describes experiments that would cause a
|
||||
standard security-aware resolver to (incorrectly) determine that
|
||||
all or part of a zone is bogus, or to otherwise not interoperate
|
||||
with standard DNSSEC clients and servers.
|
||||
|
||||
Not included in these terms are experiments with the core DNS
|
||||
protocol itself.
|
||||
|
||||
The methodology described in this document is not necessary for
|
||||
backwards-compatible experiments, although it certainly may be used
|
||||
if desired.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 5]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
4. Method
|
||||
|
||||
The core of the methodology is the use of strictly unknown algorithm
|
||||
identifiers when signing the experimental zone, and more importantly,
|
||||
having only unknown algorithm identifiers in the DS records for the
|
||||
delegation to the zone at the parent.
|
||||
|
||||
This technique works because of the way DNSSEC-compliant validators
|
||||
are expected to work in the presence of a DS set with only unknown
|
||||
algorithm identifiers. From [4], Section 5.2:
|
||||
|
||||
If the validator does not support any of the algorithms listed in
|
||||
an authenticated DS RRset, then the resolver has no supported
|
||||
authentication path leading from the parent to the child. The
|
||||
resolver should treat this case as it would the case of an
|
||||
authenticated NSEC RRset proving that no DS RRset exists, as
|
||||
described above.
|
||||
|
||||
And further:
|
||||
|
||||
If the resolver does not support any of the algorithms listed in
|
||||
an authenticated DS RRset, then the resolver will not be able to
|
||||
verify the authentication path to the child zone. In this case,
|
||||
the resolver SHOULD treat the child zone as if it were unsigned.
|
||||
|
||||
While this behavior isn't strictly mandatory (as marked by MUST), it
|
||||
is likely that a validator would implement this behavior, or, more to
|
||||
the point, it would handle this situation in a safe way (see below
|
||||
(Section 6).)
|
||||
|
||||
Because we are talking about experiments, it is RECOMMENDED that
|
||||
private algorithm numbers be used (see [3], appendix A.1.1. Note
|
||||
that secure handling of private algorithms requires special handing
|
||||
by the validator logic. See [6] for further details.) Normally,
|
||||
instead of actually inventing new signing algorithms, the recommended
|
||||
path is to create alternate algorithm identifiers that are aliases
|
||||
for the existing, known algorithms. While, strictly speaking, it is
|
||||
only necessary to create an alternate identifier for the mandatory
|
||||
algorithms, it is suggested that all optional defined algorithms be
|
||||
aliased as well.
|
||||
|
||||
It is RECOMMENDED that for a particular DNSSEC experiment, a
|
||||
particular domain name base is chosen for all new algorithms, then
|
||||
the algorithm number (or name) is prepended to it. For example, for
|
||||
experiment A, the base name of "dnssec-experiment-a.example.com" is
|
||||
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
|
||||
defined to be "3.dnssec-experiment-a.example.com" and
|
||||
"5.dnssec-experiment-a.example.com". However, any unique identifier
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 6]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
will suffice.
|
||||
|
||||
Using this method, resolvers (or, more specifically, DNSSEC
|
||||
validators) essentially indicate their ability to understand the
|
||||
DNSSEC experiment's semantics by understanding what the new algorithm
|
||||
identifiers signify.
|
||||
|
||||
This method creates two classes of security-aware servers and
|
||||
resolvers: servers and resolvers that are aware of the experiment
|
||||
(and thus recognize the experiment's algorithm identifiers and
|
||||
experimental semantics), and servers and resolvers that are unaware
|
||||
of the experiment.
|
||||
|
||||
This method also precludes any zone from being both in an experiment
|
||||
and in a classic DNSSEC island of security. That is, a zone is
|
||||
either in an experiment and only experimentally validatable, or it is
|
||||
not.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 7]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
5. Defining an Experiment
|
||||
|
||||
The DNSSEC experiment MUST define the particular set of (previously
|
||||
unknown) algorithm identifiers that identify the experiment, and
|
||||
define what each unknown algorithm identifier means. Typically,
|
||||
unless the experiment is actually experimenting with a new DNSSEC
|
||||
algorithm, this will be a mapping of private algorithm identifiers to
|
||||
existing, known algorithms.
|
||||
|
||||
Normally the experiment will choose a DNS name as the algorithm
|
||||
identifier base. This DNS name SHOULD be under the control of the
|
||||
authors of the experiment. Then the experiment will define a mapping
|
||||
between known mandatory and optional algorithms into this private
|
||||
algorithm identifier space. Alternately, the experiment MAY use the
|
||||
OID private algorithm space instead (using algorithm number 254), or
|
||||
MAY choose non-private algorithm numbers, although this would require
|
||||
an IANA allocation.
|
||||
|
||||
For example, an experiment might specify in its description the DNS
|
||||
name "dnssec-experiment-a.example.com" as the base name, and declare
|
||||
that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
|
||||
algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
|
||||
alias of DNSSEC algorithm 5 (RSASHA1).
|
||||
|
||||
Resolvers MUST only recognize the experiment's semantics when present
|
||||
in a zone signed by one or more of these algorithm identifiers. This
|
||||
is necessary to isolate the semantics of one experiment from any
|
||||
others that the resolver might understand.
|
||||
|
||||
In general, resolvers involved in the experiment are expected to
|
||||
understand both standard DNSSEC and the defined experimental DNSSEC
|
||||
protocol, although this isn't required.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 8]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
6. Considerations
|
||||
|
||||
There are a number of considerations with using this methodology.
|
||||
|
||||
1. Under some circumstances, it may be that the experiment will not
|
||||
be sufficiently masked by this technique and may cause resolution
|
||||
problem for resolvers not aware of the experiment. For instance,
|
||||
the resolver may look at a non-validatable response and conclude
|
||||
that the response is bogus, either due to local policy or
|
||||
implementation details. This is not expected to be a common
|
||||
case, however.
|
||||
|
||||
2. It will not be possible for security-aware resolvers unaware of
|
||||
the experiment to build a chain of trust through an experimental
|
||||
zone.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 9]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
7. Use in Non-Experiments
|
||||
|
||||
This general methodology MAY be used for non-backwards compatible
|
||||
DNSSEC protocol changes that start out as or become standards. In
|
||||
this case:
|
||||
|
||||
o The protocol change SHOULD use public IANA allocated algorithm
|
||||
identifiers instead of private algorithm identifiers. This will
|
||||
help identify the protocol change as a standard, rather than an
|
||||
experiment.
|
||||
|
||||
o Resolvers MAY recognize the protocol change in zones not signed
|
||||
(or not solely signed) using the new algorithm identifiers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 10]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
Zones using this methodology will be considered insecure by all
|
||||
resolvers except those aware of the experiment. It is not generally
|
||||
possible to create a secure delegation from an experimental zone that
|
||||
will be followed by resolvers unaware of the experiment.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 11]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
This document has no IANA actions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 12]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions",
|
||||
RFC 4035, March 2005.
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[5] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[6] Austein, R. and S. Weiler, "Clarifications and Implementation
|
||||
Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
|
||||
(work in progress), January 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 13]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
David Blacka
|
||||
VeriSign, Inc.
|
||||
21355 Ridgetop Circle
|
||||
Dulles, VA 20166
|
||||
US
|
||||
|
||||
Phone: +1 703 948 3200
|
||||
Email: davidb@verisign.com
|
||||
URI: http://www.verisignlabs.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 14]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 15]
|
||||
|
||||
@@ -1,616 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Weiler
|
||||
Internet-Draft SPARTA, Inc
|
||||
Updates: 4034, 4035 (if approved) J. Ihren
|
||||
Expires: July 24, 2006 Autonomica AB
|
||||
January 20, 2006
|
||||
|
||||
|
||||
Minimally Covering NSEC Records and DNSSEC On-line Signing
|
||||
draft-ietf-dnsext-dnssec-online-signing-02
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on July 24, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes how to construct DNSSEC NSEC resource records
|
||||
that cover a smaller range of names than called for by RFC4034. By
|
||||
generating and signing these records on demand, authoritative name
|
||||
servers can effectively stop the disclosure of zone contents
|
||||
otherwise made possible by walking the chain of NSEC records in a
|
||||
signed zone.
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 1]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
Changes from ietf-01 to ietf-02
|
||||
|
||||
Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
|
||||
and NSEC bits set, to be consistent with DNSSECbis -- previous text
|
||||
said SHOULD.
|
||||
|
||||
Made the applicability statement a little less oppressive.
|
||||
|
||||
Changes from ietf-00 to ietf-01
|
||||
|
||||
Added an applicability statement, making reference to ongoing work on
|
||||
NSEC3.
|
||||
|
||||
Added the phrase "epsilon functions", which has been commonly used to
|
||||
describe the technique and already appeared in the header of each
|
||||
page, in place of "increment and decrement functions". Also added an
|
||||
explanatory sentence.
|
||||
|
||||
Corrected references from 4034 section 6.2 to section 6.1.
|
||||
|
||||
Fixed an out-of-date reference to [-bis] and other typos.
|
||||
|
||||
Replaced IANA Considerations text.
|
||||
|
||||
Escaped close parentheses in examples.
|
||||
|
||||
Added some more acknowledgements.
|
||||
|
||||
Changes from weiler-01 to ietf-00
|
||||
|
||||
Inserted RFC numbers for 4033, 4034, and 4035.
|
||||
|
||||
Specified contents of bitmap field in synthesized NSEC RR's, pointing
|
||||
out that this relaxes a constraint in 4035. Added 4035 to the
|
||||
Updates header.
|
||||
|
||||
Changes from weiler-00 to weiler-01
|
||||
|
||||
Clarified that this updates RFC4034 by relaxing requirements on the
|
||||
next name field.
|
||||
|
||||
Added examples covering wildcard names.
|
||||
|
||||
In the 'better functions' section, reiterated that perfect functions
|
||||
aren't needed.
|
||||
|
||||
Added a reference to RFC 2119.
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 2]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
|
||||
2. Applicability of This Technique . . . . . . . . . . . . . . . 4
|
||||
3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
|
||||
4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
|
||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
|
||||
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
|
||||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 11
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 3]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
1. Introduction and Terminology
|
||||
|
||||
With DNSSEC [1], an NSEC record lists the next instantiated name in
|
||||
its zone, proving that no names exist in the "span" between the
|
||||
NSEC's owner name and the name in the "next name" field. In this
|
||||
document, an NSEC record is said to "cover" the names between its
|
||||
owner name and next name.
|
||||
|
||||
Through repeated queries that return NSEC records, it is possible to
|
||||
retrieve all of the names in the zone, a process commonly called
|
||||
"walking" the zone. Some zone owners have policies forbidding zone
|
||||
transfers by arbitrary clients; this side-effect of the NSEC
|
||||
architecture subverts those policies.
|
||||
|
||||
This document presents a way to prevent zone walking by constructing
|
||||
NSEC records that cover fewer names. These records can make zone
|
||||
walking take approximately as many queries as simply asking for all
|
||||
possible names in a zone, making zone walking impractical. Some of
|
||||
these records must be created and signed on demand, which requires
|
||||
on-line private keys. Anyone contemplating use of this technique is
|
||||
strongly encouraged to review the discussion of the risks of on-line
|
||||
signing in Section 6.
|
||||
|
||||
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 [4].
|
||||
|
||||
|
||||
2. Applicability of This Technique
|
||||
|
||||
The technique presented here may be useful to a zone owner that wants
|
||||
to use DNSSEC, is concerned about exposure of its zone contents via
|
||||
zone walking, and is willing to bear the costs of on-line signing.
|
||||
|
||||
As discussed in Section 6, on-line signing has several security
|
||||
risks, including an increased likelihood of private keys being
|
||||
disclosed and an increased risk of denial of service attack. Anyone
|
||||
contemplating use of this technique is strongly encouraged to review
|
||||
the discussion of the risks of on-line signing in Section 6.
|
||||
|
||||
Furthermore, at the time this document was published, the DNSEXT
|
||||
working group was actively working on a mechanism to prevent zone
|
||||
walking that does not require on-line signing (tentatively called
|
||||
NSEC3). The new mechanism is likely to expose slightly more
|
||||
information about the zone than this technique (e.g. the number of
|
||||
instantiated names), but it may be preferable to this technique.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 4]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
3. Minimally Covering NSEC Records
|
||||
|
||||
This mechanism involves changes to NSEC records for instantiated
|
||||
names, which can still be generated and signed in advance, as well as
|
||||
the on-demand generation and signing of new NSEC records whenever a
|
||||
name must be proven not to exist.
|
||||
|
||||
In the 'next name' field of instantiated names' NSEC records, rather
|
||||
than list the next instantiated name in the zone, list any name that
|
||||
falls lexically after the NSEC's owner name and before the next
|
||||
instantiated name in the zone, according to the ordering function in
|
||||
RFC4034 [2] section 6.1. This relaxes the requirement in section
|
||||
4.1.1 of RFC4034 that the 'next name' field contains the next owner
|
||||
name in the zone. This change is expected to be fully compatible
|
||||
with all existing DNSSEC validators. These NSEC records are returned
|
||||
whenever proving something specifically about the owner name (e.g.
|
||||
that no resource records of a given type appear at that name).
|
||||
|
||||
Whenever an NSEC record is needed to prove the non-existence of a
|
||||
name, a new NSEC record is dynamically produced and signed. The new
|
||||
NSEC record has an owner name lexically before the QNAME but
|
||||
lexically following any existing name and a 'next name' lexically
|
||||
following the QNAME but before any existing name.
|
||||
|
||||
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
|
||||
bits set and SHOULD NOT have any other bits set. 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.
|
||||
|
||||
The functions to generate the lexically following and proceeding
|
||||
names need not be perfect nor consistent, but the generated NSEC
|
||||
records must not cover any existing names. Furthermore, this
|
||||
technique works best when the generated NSEC records cover as few
|
||||
names as possible. In this document, the functions that generate the
|
||||
nearby names are called 'epsilon' functions, a reference to the
|
||||
mathematical convention of using the greek letter epsilon to
|
||||
represent small deviations.
|
||||
|
||||
An NSEC record denying the existence of a wildcard may be generated
|
||||
in the same way. Since the NSEC record covering a non-existent
|
||||
wildcard is likely to be used in response to many queries,
|
||||
authoritative name servers using the techniques described here may
|
||||
want to pregenerate or cache that record and its corresponding RRSIG.
|
||||
|
||||
For example, a query for an A record at the non-instantiated name
|
||||
example.com might produce the following two NSEC records, the first
|
||||
denying the existence of the name example.com and the second denying
|
||||
the existence of a wildcard:
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 5]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
|
||||
|
||||
\).com 3600 IN NSEC +.com ( RRSIG NSEC )
|
||||
|
||||
Before answering a query with these records, an authoritative server
|
||||
must test for the existence of names between these endpoints. If the
|
||||
generated NSEC would cover existing names (e.g. exampldd.com or
|
||||
*bizarre.example.com), a better epsilon function may be used or the
|
||||
covered name closest to the QNAME could be used as the NSEC owner
|
||||
name or next name, as appropriate. If an existing name is used as
|
||||
the NSEC owner name, that name's real NSEC record MUST be returned.
|
||||
Using the same example, assuming an exampldd.com delegation exists,
|
||||
this record might be returned from the parent:
|
||||
|
||||
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
|
||||
|
||||
Like every authoritative record in the zone, each generated NSEC
|
||||
record MUST have corresponding RRSIGs generated using each algorithm
|
||||
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
|
||||
described in RFC4035 [3] section 2.2. To minimize the number of
|
||||
signatures that must be generated, a zone may wish to limit the
|
||||
number of algorithms in its DNSKEY RRset.
|
||||
|
||||
|
||||
4. Better Epsilon Functions
|
||||
|
||||
Section 6.1 of RFC4034 defines a strict ordering of DNS names.
|
||||
Working backwards from that definition, it should be possible to
|
||||
define epsilon functions that generate the immediately following and
|
||||
preceding names, respectively. This document does not define such
|
||||
functions. Instead, this section presents functions that come
|
||||
reasonably close to the perfect ones. As described above, an
|
||||
authoritative server should still ensure than no generated NSEC
|
||||
covers any existing name.
|
||||
|
||||
To increment a name, add a leading label with a single null (zero-
|
||||
value) octet.
|
||||
|
||||
To decrement a name, decrement the last character of the leftmost
|
||||
label, then fill that label to a length of 63 octets with octets of
|
||||
value 255. To decrement a null (zero-value) octet, remove the octet
|
||||
-- if an empty label is left, remove the label. Defining this
|
||||
function numerically: fill the left-most label to its maximum length
|
||||
with zeros (numeric, not ASCII zeros) and subtract one.
|
||||
|
||||
In response to a query for the non-existent name foo.example.com,
|
||||
these functions produce NSEC records of:
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 6]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
|
||||
|
||||
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
|
||||
|
||||
The first of these NSEC RRs proves that no exact match for
|
||||
foo.example.com exists, and the second proves that there is no
|
||||
wildcard in example.com.
|
||||
|
||||
Both of these functions are imperfect: they don't take into account
|
||||
constraints on number of labels in a name nor total length of a name.
|
||||
As noted in the previous section, though, this technique does not
|
||||
depend on the use of perfect epsilon functions: it is sufficient to
|
||||
test whether any instantiated names fall into the span covered by the
|
||||
generated NSEC and, if so, substitute those instantiated owner names
|
||||
for the NSEC owner name or next name, as appropriate.
|
||||
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
This document specifies no IANA Actions.
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
This approach requires on-demand generation of RRSIG records. This
|
||||
creates several new vulnerabilities.
|
||||
|
||||
First, on-demand signing requires that a zone's authoritative servers
|
||||
have access to its private keys. Storing private keys on well-known
|
||||
internet-accessible servers may make them more vulnerable to
|
||||
unintended disclosure.
|
||||
|
||||
Second, since generation of digital signatures tends to be
|
||||
computationally demanding, the requirement for on-demand signing
|
||||
makes authoritative servers vulnerable to a denial of service attack.
|
||||
|
||||
Lastly, if the epsilon functions are predictable, on-demand signing
|
||||
may enable a chosen-plaintext attack on a zone's private keys. Zones
|
||||
using this approach should attempt to use cryptographic algorithms
|
||||
that are resistant to chosen-plaintext attacks. It's worth noting
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 7]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
that while DNSSEC has a "mandatory to implement" algorithm, that is a
|
||||
requirement on resolvers and validators -- there is no requirement
|
||||
that a zone be signed with any given algorithm.
|
||||
|
||||
The success of using minimally covering NSEC record to prevent zone
|
||||
walking depends greatly on the quality of the epsilon functions
|
||||
chosen. An increment function that chooses a name obviously derived
|
||||
from the next instantiated name may be easily reverse engineered,
|
||||
destroying the value of this technique. An increment function that
|
||||
always returns a name close to the next instantiated name is likewise
|
||||
a poor choice. Good choices of epsilon functions are the ones that
|
||||
produce the immediately following and preceding names, respectively,
|
||||
though zone administrators may wish to use less perfect functions
|
||||
that return more human-friendly names than the functions described in
|
||||
Section 4 above.
|
||||
|
||||
Another obvious but misguided concern is the danger from synthesized
|
||||
NSEC records being replayed. It's possible for an attacker to replay
|
||||
an old but still validly signed NSEC record after a new name has been
|
||||
added in the span covered by that NSEC, incorrectly proving that
|
||||
there is no record at that name. This danger exists with DNSSEC as
|
||||
defined in [3]. The techniques described here actually decrease the
|
||||
danger, since the span covered by any NSEC record is smaller than
|
||||
before. Choosing better epsilon functions will further reduce this
|
||||
danger.
|
||||
|
||||
7. Normative References
|
||||
|
||||
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions",
|
||||
RFC 4035, March 2005.
|
||||
|
||||
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
Appendix A. Acknowledgments
|
||||
|
||||
Many individuals contributed to this design. They include, in
|
||||
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 8]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
|
||||
Jakob Schlyter, Bill Manning, and Joao Damas.
|
||||
|
||||
In addition, the editors would like to thank Ed Lewis, Scott Rose,
|
||||
and David Blacka for their careful review of the document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 9]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Samuel Weiler
|
||||
SPARTA, Inc
|
||||
7075 Samuel Morse Drive
|
||||
Columbia, Maryland 21046
|
||||
US
|
||||
|
||||
Email: weiler@tislabs.com
|
||||
|
||||
|
||||
Johan Ihren
|
||||
Autonomica AB
|
||||
Bellmansgatan 30
|
||||
Stockholm SE-118 47
|
||||
Sweden
|
||||
|
||||
Email: johani@autonomica.se
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 10]
|
||||
|
||||
Internet-Draft NSEC Epsilon January 2006
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Expires July 24, 2006 [Page 11]
|
||||
|
||||
@@ -1,504 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group W. Hardaker
|
||||
Internet-Draft Sparta
|
||||
Expires: August 25, 2006 February 21, 2006
|
||||
|
||||
|
||||
Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
|
||||
draft-ietf-dnsext-ds-sha256-05.txt
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on August 25, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document specifies how to use the SHA-256 digest type in DNS
|
||||
Delegation Signer (DS) Resource Records (RRs). DS records, when
|
||||
stored in a parent zone, point to key signing DNSKEY key(s) in a
|
||||
child zone.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 1]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Implementing the SHA-256 algorithm for DS record support . . . 3
|
||||
2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
|
||||
2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
|
||||
2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
|
||||
3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
|
||||
4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
|
||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
|
||||
6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
|
||||
6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
|
||||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
|
||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 9
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 2]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
|
||||
zones to distribute a cryptographic digest of a child's Key Signing
|
||||
Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
|
||||
parent zone's private zone data signing keys for each algorithm in
|
||||
use by the parent. Each signature is published in an RRSIG resource
|
||||
record, owned by the same domain as the DS RRset and with a type
|
||||
covered of DS.
|
||||
|
||||
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 [RFC2119].
|
||||
|
||||
|
||||
2. Implementing the SHA-256 algorithm for DS record support
|
||||
|
||||
This document specifies that the digest type code [XXX: To be
|
||||
assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
|
||||
[SHA256CODE] for use within DS records. The results of the digest
|
||||
algorithm MUST NOT be truncated and the entire 32 byte digest result
|
||||
is to be published in the DS record.
|
||||
|
||||
2.1. DS record field values
|
||||
|
||||
Using the SHA-256 digest algorithm within a DS record will make use
|
||||
of the following DS-record fields:
|
||||
|
||||
Digest type: [XXX: To be assigned by IANA; likely 2]
|
||||
|
||||
Digest: A SHA-256 bit digest value calculated by using the following
|
||||
formula ("|" denotes concatenation). The resulting value is not
|
||||
truncated and the entire 32 byte result is to used in the
|
||||
resulting DS record and related calculations.
|
||||
|
||||
digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
|
||||
|
||||
where DNSKEY RDATA is defined by [RFC4034] as:
|
||||
|
||||
DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
|
||||
|
||||
The Key Tag field and Algorithm fields remain unchanged by this
|
||||
document and are specified in the [RFC4034] specification.
|
||||
|
||||
2.2. DS Record with SHA-256 Wire Format
|
||||
|
||||
The resulting on-the-wire format for the resulting DS record will be
|
||||
[XXX: IANA assignment should replace the 2 below]:
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 3]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Key Tag | Algorithm | DigestType=2 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ /
|
||||
/ Digest (length for SHA-256 is 32 bytes) /
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|
||||
|
||||
2.3. Example DS Record Using SHA-256
|
||||
|
||||
The following is an example DNSKEY and matching DS record. This
|
||||
DNSKEY record comes from the example DNSKEY/DS records found in
|
||||
section 5.4 of [RFC4034].
|
||||
|
||||
The DNSKEY record:
|
||||
|
||||
dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
|
||||
fwJr1AYtsmx3TGkJaNXVbfi/
|
||||
2pHm822aJ5iI9BMzNXxeYCmZ
|
||||
DRD99WYwYqUSdjMmmAphXdvx
|
||||
egXd/M5+X7OrzKBaMbCVdFLU
|
||||
Uh6DhweJBjEVv5f2wwjM9Xzc
|
||||
nOf+EPbtG9DMBmADjFDc2w/r
|
||||
ljwvFw==
|
||||
) ; key id = 60485
|
||||
|
||||
The resulting DS record covering the above DNSKEY record using a SHA-
|
||||
256 digest: [RFC Editor: please replace XXX with the assigned digest
|
||||
type (likely 2):]
|
||||
|
||||
dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
|
||||
CEB1E3E0614B93C4F9E99B83
|
||||
83F6A1E4469DA50A )
|
||||
|
||||
|
||||
3. Implementation Requirements
|
||||
|
||||
Implementations MUST support the use of the SHA-256 algorithm in DS
|
||||
RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
|
||||
digests if DS RRs with SHA-256 digests are present in the DS RRset.
|
||||
|
||||
|
||||
4. Deployment Considerations
|
||||
|
||||
If a validator does not support the SHA-256 digest type and no other
|
||||
DS RR exists in a zone's DS RRset with a supported digest type, then
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 4]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
the validator has no supported authentication path leading from the
|
||||
parent to the child. The resolver should treat this case as it would
|
||||
the case of an authenticated NSEC RRset proving that no DS RRset
|
||||
exists, as described in [RFC4035], section 5.2.
|
||||
|
||||
Because zone administrators can not control the deployment speed of
|
||||
support for SHA-256 in validators that may be referencing any of
|
||||
their zones, zone operators should consider deploying both SHA-1 and
|
||||
SHA-256 based DS records. This should be done for every DNSKEY for
|
||||
which DS records are being generated. Whether to make use of both
|
||||
digest types and for how long is a policy decision that extends
|
||||
beyond the scope of this document.
|
||||
|
||||
|
||||
5. IANA Considerations
|
||||
|
||||
Only one IANA action is required by this document:
|
||||
|
||||
The Digest Type to be used for supporting SHA-256 within DS records
|
||||
needs to be assigned by IANA. This document requests that the Digest
|
||||
Type value of 2 be assigned to the SHA-256 digest algorithm.
|
||||
|
||||
At the time of this writing, the current digest types assigned for
|
||||
use in DS records are as follows:
|
||||
|
||||
VALUE Digest Type Status
|
||||
0 Reserved -
|
||||
1 SHA-1 MANDATORY
|
||||
2 SHA-256 MANDATORY
|
||||
3-255 Unassigned -
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
6.1. Potential Digest Type Downgrade Attacks
|
||||
|
||||
A downgrade attack from a stronger digest type to a weaker one is
|
||||
possible if all of the following are true:
|
||||
|
||||
o A zone includes multiple DS records for a given child's DNSKEY,
|
||||
each of which use a different digest type.
|
||||
|
||||
o A validator accepts a weaker digest even if a stronger one is
|
||||
present but invalid.
|
||||
|
||||
For example, if the following conditions are all true:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 5]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
o Both SHA-1 and SHA-256 based digests are published in DS records
|
||||
within a parent zone for a given child zone's DNSKEY.
|
||||
|
||||
o The DS record with the SHA-1 digest matches the digest computed
|
||||
using the child zone's DNSKEY.
|
||||
|
||||
o The DS record with the SHA-256 digest fails to match the digest
|
||||
computed using the child zone's DNSKEY.
|
||||
|
||||
Then if the validator accepts the above situation as secure then this
|
||||
can be used as a downgrade attack since the stronger SHA-256 digest
|
||||
is ignored.
|
||||
|
||||
6.2. SHA-1 vs SHA-256 Considerations for DS Records
|
||||
|
||||
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
|
||||
implementations allow for it. SHA-256 is widely believed to be more
|
||||
resilient to attack than SHA-1, and confidence in SHA-1's strength is
|
||||
being eroded by recently-announced attacks. Regardless of whether or
|
||||
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
|
||||
time of this writing) that SHA-256 is the better choice for use in DS
|
||||
records.
|
||||
|
||||
At the time of this publication, the SHA-256 digest algorithm is
|
||||
considered sufficiently strong for the immediate future. It is also
|
||||
considered sufficient for use in DNSSEC DS RRs for the immediate
|
||||
future. However, future published attacks may weaken the usability
|
||||
of this algorithm within the DS RRs. It is beyond the scope of this
|
||||
document to speculate extensively on the cryptographic strength of
|
||||
the SHA-256 digest algorithm.
|
||||
|
||||
Likewise, it is also beyond the scope of this document to specify
|
||||
whether or for how long SHA-1 based DS records should be
|
||||
simultaneously published alongside SHA-256 based DS records.
|
||||
|
||||
|
||||
7. Acknowledgments
|
||||
|
||||
This document is a minor extension to the existing DNSSEC documents
|
||||
and those authors are gratefully appreciated for the hard work that
|
||||
went into the base documents.
|
||||
|
||||
The following people contributed to portions of this document in some
|
||||
fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
|
||||
Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
|
||||
Weiler.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 6]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
8. References
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements",
|
||||
RFC 4033, March 2005.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
[SHA256] National Institute of Standards and Technology, "Secure
|
||||
Hash Algorithm. NIST FIPS 180-2", August 2002.
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[SHA256CODE]
|
||||
Eastlake, D., "US Secure Hash Algorithms (SHA)",
|
||||
June 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 7]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Wes Hardaker
|
||||
Sparta
|
||||
P.O. Box 382
|
||||
Davis, CA 95617
|
||||
US
|
||||
|
||||
Email: hardaker@tislabs.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 8]
|
||||
|
||||
Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 25, 2006 [Page 9]
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,840 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group R. Austein
|
||||
Internet-Draft ISC
|
||||
Expires: July 15, 2006 January 11, 2006
|
||||
|
||||
|
||||
DNS Name Server Identifier Option (NSID)
|
||||
draft-ietf-dnsext-nsid-01
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on July 15, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
With the increased use of DNS anycast, load balancing, and other
|
||||
mechanisms allowing more than one DNS name server to share a single
|
||||
IP address, it is sometimes difficult to tell which of a pool of name
|
||||
servers has answered a particular query. While existing ad-hoc
|
||||
mechanism allow an operator to send follow-up queries when it is
|
||||
necessary to debug such a configuration, the only completely reliable
|
||||
way to obtain the identity of the name server which responded is to
|
||||
have the name server include this information in the response itself.
|
||||
This note defines a protocol extension to support this functionality.
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 1]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4
|
||||
2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5
|
||||
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8
|
||||
3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8
|
||||
3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
|
||||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
|
||||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
|
||||
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 15
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 2]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
With the increased use of DNS anycast, load balancing, and other
|
||||
mechanisms allowing more than one DNS name server to share a single
|
||||
IP address, it is sometimes difficult to tell which of a pool of name
|
||||
servers has answered a particular query.
|
||||
|
||||
Existing ad-hoc mechanisms allow an operator to send follow-up
|
||||
queries when it is necessary to debug such a configuration, but there
|
||||
are situations in which this is not a totally satisfactory solution,
|
||||
since anycast routing may have changed, or the server pool in
|
||||
question may be behind some kind of extremely dynamic load balancing
|
||||
hardware. Thus, while these ad-hoc mechanisms are certainly better
|
||||
than nothing (and have the advantage of already being deployed), a
|
||||
better solution seems desirable.
|
||||
|
||||
Given that a DNS query is an idempotent operation with no retained
|
||||
state, it would appear that the only completely reliable way to
|
||||
obtain the identity of the name server which responded to a
|
||||
particular query is to have that name server include identifying
|
||||
information in the response itself. This note defines a protocol
|
||||
enhancement to achieve this.
|
||||
|
||||
1.1. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 3]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
2. Protocol
|
||||
|
||||
This note uses an EDNS [RFC2671] option to signal the resolver's
|
||||
desire for information identifying the name server and to hold the
|
||||
name server's response, if any.
|
||||
|
||||
2.1. Resolver Behavior
|
||||
|
||||
A resolver signals its desire for information identifying a name
|
||||
server by sending an empty NSID option (Section 2.3) in an EDNS OPT
|
||||
pseudo-RR in the query message.
|
||||
|
||||
The resolver MUST NOT include any NSID payload data in the query
|
||||
message.
|
||||
|
||||
The semantics of an NSID request are not transitive. That is: the
|
||||
presence of an NSID option in a query is a request that the name
|
||||
server which receives the query identify itself. If the name server
|
||||
side of a recursive name server receives an NSID request, the client
|
||||
is asking the recursive name server to identify itself; if the
|
||||
resolver side of the recursive name server wishes to receive
|
||||
identifying information, it is free to add NSID requests in its own
|
||||
queries, but that is a separate matter.
|
||||
|
||||
2.2. Name Server Behavior
|
||||
|
||||
A name server which understands the NSID option and chooses to honor
|
||||
a particular NSID request responds by including identifying
|
||||
information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
|
||||
in the response message.
|
||||
|
||||
The name server MUST ignore any NSID payload data that might be
|
||||
present in the query message.
|
||||
|
||||
The NSID option is not transitive. A name server MUST NOT send an
|
||||
NSID option back to a resolver which did not request it. In
|
||||
particular, while a recursive name server may choose to add an NSID
|
||||
option when sending a query, this has no effect on the presence or
|
||||
absence of the NSID option in the recursive name server's response to
|
||||
the original client.
|
||||
|
||||
As stated in Section 2.1, this mechanism is not restricted to
|
||||
authoritative name servers; the semantics are intended to be equally
|
||||
applicable to recursive name servers.
|
||||
|
||||
2.3. The NSID Option
|
||||
|
||||
The OPTION-CODE for the NSID option is [TBD].
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 4]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
The OPTION-DATA for the NSID option is an opaque byte string the
|
||||
semantics of which are deliberately left outside the protocol. See
|
||||
Section 3.1 for discussion.
|
||||
|
||||
2.4. Presentation Format
|
||||
|
||||
User interfaces MUST read and write the content of the NSID option as
|
||||
a sequence of hexadecimal digits, two digits per payload octet.
|
||||
|
||||
The NSID payload is binary data. Any comparison between NSID
|
||||
payloads MUST be a comparison of the raw binary data. Copy
|
||||
operations MUST NOT assume that the raw NSID payload is null-
|
||||
terminated. Any resemblance between raw NSID payload data and any
|
||||
form of text is purely a convenience, and does not change the
|
||||
underlying nature of the payload data.
|
||||
|
||||
See Section 3.3 for discussion.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 5]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
3. Discussion
|
||||
|
||||
This section discusses certain aspects of the protocol and explains
|
||||
considerations that led to the chosen design.
|
||||
|
||||
3.1. The NSID Payload
|
||||
|
||||
The syntax and semantics of the content of the NSID option is
|
||||
deliberately left outside the scope of this specification. This
|
||||
section describe some of the kinds of data that server administrators
|
||||
might choose to provide as the content of the NSID option, and
|
||||
explains the reasoning behind choosing a simple opaque byte string.
|
||||
|
||||
There are several possibilities for the payload of the NSID option:
|
||||
|
||||
o It could be the "real" name of the specific name server within the
|
||||
name server pool.
|
||||
|
||||
o It could be the "real" IP address (IPv4 or IPv6) of the name
|
||||
server within the name server pool.
|
||||
|
||||
o It could be some sort of pseudo-random number generated in a
|
||||
predictable fashion somehow using the server's IP address or name
|
||||
as a seed value.
|
||||
|
||||
o It could be some sort of probabilisticly unique identifier
|
||||
initially derived from some sort of random number generator then
|
||||
preserved across reboots of the name server.
|
||||
|
||||
o It could be some sort of dynamicly generated identifier so that
|
||||
only the name server operator could tell whether or not any two
|
||||
queries had been answered by the same server.
|
||||
|
||||
o It could be a blob of signed data, with a corresponding key which
|
||||
might (or might not) be available via DNS lookups.
|
||||
|
||||
o It could be a blob of encrypted data, the key for which could be
|
||||
restricted to parties with a need to know (in the opinion of the
|
||||
server operator).
|
||||
|
||||
o It could be an arbitrary string of octets chosen at the discretion
|
||||
of the name server operator.
|
||||
|
||||
Each of these options has advantages and disadvantages:
|
||||
|
||||
o Using the "real" name is simple, but the name server may not have
|
||||
a "real" name.
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 6]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
o Using the "real" address is also simple, and the name server
|
||||
almost certainly does have at least one non-anycast IP address for
|
||||
maintenance operations, but the operator of the name server may
|
||||
not be willing to divulge its non-anycast address.
|
||||
|
||||
o Given that one common reason for using anycast DNS techniques is
|
||||
an attempt to harden a critical name server against denial of
|
||||
service attacks, some name server operators are likely to want an
|
||||
identifier other than the "real" name or "real" address of the
|
||||
name server instance.
|
||||
|
||||
o Using a hash or pseudo-random number can provide a fixed length
|
||||
value that the resolver can use to tell two name servers apart
|
||||
without necessarily being able to tell where either one of them
|
||||
"really" is, but makes debugging more difficult if one happens to
|
||||
be in a friendly open environment. Furthermore, hashing might not
|
||||
add much value, since a hash based on an IPv4 address still only
|
||||
involves a 32-bit search space, and DNS names used for servers
|
||||
that operators might have to debug at 4am tend not to be very
|
||||
random.
|
||||
|
||||
o Probabilisticly unique identifiers have similar properties to
|
||||
hashed identifiers, but (given a sufficiently good random number
|
||||
generator) are immune to the search space issues. However, the
|
||||
strength of this approach is also its weakness: there is no
|
||||
algorithmic transformation by which even the server operator can
|
||||
associate name server instances with identifiers while debugging,
|
||||
which might be annoying. This approach also requires the name
|
||||
server instance to preserve the probabilisticly unique identifier
|
||||
across reboots, but this does not appear to be a serious
|
||||
restriction, since authoritative nameservers almost always have
|
||||
some form of nonvolatile storage in any case, and in the rare case
|
||||
of a name server that does not have any way to store such an
|
||||
identifier, nothing terrible will happen if the name server just
|
||||
generates a new identifier every time it reboots.
|
||||
|
||||
o Using an arbitrary octet string gives name server operators yet
|
||||
another thing to configure, or mis-configure, or forget to
|
||||
configure. Having all the nodes in an anycast name server
|
||||
constellation identify themselves as "My Name Server" would not be
|
||||
particularly useful.
|
||||
|
||||
Given all of the issues listed above, there does not appear to be a
|
||||
single solution that will meet all needs. Section 2.3 therefore
|
||||
defines the NSID payload to be an opaque byte string and leaves the
|
||||
choice up to the implementor and name server operator. The following
|
||||
guidelines may be useful to implementors and server operators:
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 7]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
o Operators for whom divulging the unicast address is an issue could
|
||||
use the raw binary representation of a probabilisticly unique
|
||||
random number. This should probably be the default implementation
|
||||
behavior.
|
||||
|
||||
o Operators for whom divulging the unicast address is not an issue
|
||||
could just use the raw binary representation of a unicast address
|
||||
for simplicity. This should only be done via an explicit
|
||||
configuration choice by the operator.
|
||||
|
||||
o Operators who really need or want the ability to set the NSID
|
||||
payload to an arbitrary value could do so, but this should only be
|
||||
done via an explicit configuration choice by the operator.
|
||||
|
||||
This approach appears to provide enough information for useful
|
||||
debugging without unintentionally leaking the maintenance addresses
|
||||
of anycast name servers to nogoodniks, while also allowing name
|
||||
server operators who do not find such leakage threatening to provide
|
||||
more information at their own discretion.
|
||||
|
||||
3.2. NSID Is Not Transitive
|
||||
|
||||
As specified in Section 2.1 and Section 2.2, the NSID option is not
|
||||
transitive. This is strictly a hop-by-hop mechanism.
|
||||
|
||||
Most of the discussion of name server identification to date has
|
||||
focused on identifying authoritative name servers, since the best
|
||||
known cases of anycast name servers are a subset of the name servers
|
||||
for the root zone. However, given that anycast DNS techniques are
|
||||
also applicable to recursive name servers, the mechanism may also be
|
||||
useful with recursive name servers. The hop-by-hop semantics support
|
||||
this.
|
||||
|
||||
While there might be some utility in having a transitive variant of
|
||||
this mechanism (so that, for example, a stub resolver could ask a
|
||||
recursive server to tell it which authoritative name server provided
|
||||
a particular answer to the recursive name server), the semantics of
|
||||
such a variant would be more complicated, and are left for future
|
||||
work.
|
||||
|
||||
3.3. User Interface Issues
|
||||
|
||||
Given the range of possible payload contents described in
|
||||
Section 3.1, it is not possible to define a single presentation
|
||||
format for the NSID payload that is efficient, convenient,
|
||||
unambiguous, and aesthetically pleasing. In particular, while it is
|
||||
tempting to use a presentation format that uses some form of textual
|
||||
strings, attempting to support this would significantly complicate
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 8]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
what's intended to be a very simple debugging mechanism.
|
||||
|
||||
In some cases the content of the NSID payload may be binary data
|
||||
meaningful only to the name server operator, and may not be
|
||||
meaningful to the user or application, but the user or application
|
||||
must be able to capture the entire content anyway in order for it to
|
||||
be useful. Thus, the presentation format must support arbitrary
|
||||
binary data.
|
||||
|
||||
In cases where the name server operator derives the NSID payload from
|
||||
textual data, a textual form such as US-ASCII or UTF-8 strings might
|
||||
at first glance seem easier for a user to deal with. There are,
|
||||
however, a number of complex issues involving internationalized text
|
||||
which, if fully addressed here, would require a set of rules
|
||||
significantly longer than the rest of this specification. See
|
||||
[RFC2277] for an overview of some of these issues.
|
||||
|
||||
It is much more important for the NSID payload data to be passed
|
||||
unambiguously from server administrator to user and back again than
|
||||
it is for the payload data data to be pretty while in transit. In
|
||||
particular, it's critical that it be straightforward for a user to
|
||||
cut and paste an exact copy of the NSID payload output by a debugging
|
||||
tool into other formats such as email messages or web forms without
|
||||
distortion. Hexadecimal strings, while ugly, are also robust.
|
||||
|
||||
3.4. Truncation
|
||||
|
||||
In some cases, adding the NSID option to a response message may
|
||||
trigger message truncation. This specification does not change the
|
||||
rules for DNS message truncation in any way, but implementors will
|
||||
need to pay attention to this issue.
|
||||
|
||||
Including the NSID option in a response is always optional, so this
|
||||
specification never requires name servers to truncate response
|
||||
messages.
|
||||
|
||||
By definition, a resolver that requests NSID responses also supports
|
||||
EDNS, so a resolver that requests NSID responses can also use the
|
||||
"sender's UDP payload size" field of the OPT pseudo-RR to signal a
|
||||
receive buffer size large enough to make truncation unlikely.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 9]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
This mechanism requires allocation of one ENDS option code for the
|
||||
NSID option (Section 2.3).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 10]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This document describes a channel signaling mechanism, intended
|
||||
primarily for debugging. Channel signaling mechanisms are outside
|
||||
the scope of DNSSEC per se. Applications that require integrity
|
||||
protection for the data being signaled will need to use a channel
|
||||
security mechanism such as TSIG [RFC2845].
|
||||
|
||||
Section 3.1 discusses a number of different kinds of information that
|
||||
a name server operator might choose to provide as the value of the
|
||||
NSID option. Some of these kinds of information are security
|
||||
sensitive in some environments. This specification deliberately
|
||||
leaves the syntax and semantics of the NSID option content up to the
|
||||
implementation and the name server operator.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 11]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
|
||||
Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
|
||||
Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
|
||||
Suzanne Woolf. Apologies to anyone inadvertently omitted from the
|
||||
above list.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 12]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
7. References
|
||||
|
||||
7.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, BCP 14, March 1997.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
|
||||
RFC 2671, August 1999.
|
||||
|
||||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
7.2. Informative References
|
||||
|
||||
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
|
||||
Languages", RFC 2277, BCP 18, January 1998.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 13]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Rob Austein
|
||||
ISC
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
USA
|
||||
|
||||
Email: sra@isc.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 14]
|
||||
|
||||
Internet-Draft DNS NSID January 2006
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Austein Expires July 15, 2006 [Page 15]
|
||||
|
||||
@@ -1,464 +0,0 @@
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
Expires: September 2006 March 2006
|
||||
|
||||
|
||||
DSA Keying and Signature Information in the DNS
|
||||
--- ------ --- --------- ----------- -- --- ---
|
||||
<draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
|
||||
Donald E. Eastlake 3rd
|
||||
|
||||
|
||||
Status of This Document
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Distribution of this document is unlimited. Comments should be sent
|
||||
to the DNS extensions working group mailing list
|
||||
<namedroppers@ops.ietf.org>.
|
||||
|
||||
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/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The standard method of encoding US Government Digital Signature
|
||||
Algorithm keying and signature information for use in the Domain Name
|
||||
System is specified.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 1]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
Status of This Document....................................1
|
||||
Abstract...................................................1
|
||||
|
||||
Table of Contents..........................................2
|
||||
|
||||
1. Introduction............................................3
|
||||
2. DSA Keying Information..................................3
|
||||
3. DSA Signature Information...............................4
|
||||
4. Performance Considerations..............................4
|
||||
5. Security Considerations.................................5
|
||||
6. IANA Considerations.....................................5
|
||||
Copyright, Disclaimer, and Additional IPR Provisions.......5
|
||||
|
||||
Normative References.......................................7
|
||||
Informative References.....................................7
|
||||
|
||||
Author's Address...........................................8
|
||||
Expiration and File Name...................................8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 2]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
other information [RFC 1034, 1035]. The DNS has been extended to
|
||||
include digital signatures and cryptographic keys as described in
|
||||
[RFC 4033, 4034, 4035] and additional work is underway which would
|
||||
require the storage of keying and signature information in the DNS.
|
||||
|
||||
This document describes how to encode US Government Digital Signature
|
||||
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
|
||||
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
|
||||
|
||||
|
||||
|
||||
2. DSA Keying Information
|
||||
|
||||
When DSA public keys are stored in the DNS, the structure of the
|
||||
relevant part of the RDATA part of the RR being used is the fields
|
||||
listed below in the order given.
|
||||
|
||||
The period of key validity is not included in this data but is
|
||||
indicated separately, for example by an RR such as RRSIG which signs
|
||||
and authenticates the RR containing the keying information.
|
||||
|
||||
Field Size
|
||||
----- ----
|
||||
T 1 octet
|
||||
Q 20 octets
|
||||
P 64 + T*8 octets
|
||||
G 64 + T*8 octets
|
||||
Y 64 + T*8 octets
|
||||
|
||||
As described in [FIPS 186-2] and [Schneier], T is a key size
|
||||
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
|
||||
is greater than 8 is reserved and the remainder of the data may have
|
||||
a different format in that case.) Q is a prime number selected at
|
||||
key generation time such that 2**159 < Q < 2**160. Thus Q is always
|
||||
20 octets long and, as with all other fields, is stored in "big-
|
||||
endian" network order. P, G, and Y are calculated as directed by the
|
||||
[FIPS 186-2] key generation algorithm [Schneier]. P is in the range
|
||||
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
|
||||
and Y are quantities modulo P and so can be up to the same length as
|
||||
P and are allocated fixed size fields with the same number of octets
|
||||
as P.
|
||||
|
||||
During the key generation process, a random number X must be
|
||||
generated such that 1 <= X <= Q-1. X is the private key and is used
|
||||
in the final step of public key generation where Y is computed as
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 3]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Y = G**X mod P
|
||||
|
||||
|
||||
|
||||
3. DSA Signature Information
|
||||
|
||||
The portion of the RDATA area used for US Digital Signature Algorithm
|
||||
signature information is shown below with fields in the order they
|
||||
are listed and the contents of each multi-octet field in "big-endian"
|
||||
network order.
|
||||
|
||||
Field Size
|
||||
----- ----
|
||||
T 1 octet
|
||||
R 20 octets
|
||||
S 20 octets
|
||||
|
||||
First, the data signed must be determined. Then the following steps
|
||||
are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
|
||||
specified in the public key [Schneier]:
|
||||
|
||||
hash = SHA-1 ( data )
|
||||
|
||||
Generate a random K such that 0 < K < Q.
|
||||
|
||||
R = ( G**K mod P ) mod Q
|
||||
|
||||
S = ( K**(-1) * (hash + X*R) ) mod Q
|
||||
|
||||
For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
|
||||
3174].
|
||||
|
||||
Since Q is 160 bits long, R and S can not be larger than 20 octets,
|
||||
which is the space allocated.
|
||||
|
||||
T is copied from the public key. It is not logically necessary in
|
||||
the SIG but is present so that values of T > 8 can more conveniently
|
||||
be used as an escape for extended versions of DSA or other algorithms
|
||||
as later standardized.
|
||||
|
||||
|
||||
|
||||
4. Performance Considerations
|
||||
|
||||
General signature generation speeds are roughly the same for RSA [RFC
|
||||
3110] and DSA. With sufficient pre-computation, signature generation
|
||||
with DSA is faster than RSA. Key generation is also faster for DSA.
|
||||
However, signature verification is an order of magnitude slower than
|
||||
RSA when the RSA public exponent is chosen to be small, as is
|
||||
recommended for some applications.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 4]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Current DNS implementations are optimized for small transfers,
|
||||
typically less than 512 bytes including DNS overhead. Larger
|
||||
transfers will perform correctly and extensions have been
|
||||
standardized [RFC 2671] to make larger transfers more efficient, it
|
||||
is still advisable at this time to make reasonable efforts to
|
||||
minimize the size of RR sets containing keying and/or signature
|
||||
inforamtion consistent with adequate security.
|
||||
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Keys retrieved from the DNS should not be trusted unless (1) they
|
||||
have been securely obtained from a secure resolver or independently
|
||||
verified by the user and (2) this secure resolver and secure
|
||||
obtainment or independent verification conform to security policies
|
||||
acceptable to the user. As with all cryptographic algorithms,
|
||||
evaluating the necessary strength of the key is essential and
|
||||
dependent on local policy.
|
||||
|
||||
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
|
||||
current DSA standard may limit the security of DSA. For particular
|
||||
applications, implementors are encouraged to consider the range of
|
||||
available algorithms and key sizes.
|
||||
|
||||
DSA assumes the ability to frequently generate high quality random
|
||||
numbers. See [random] for guidance. DSA is designed so that if
|
||||
biased rather than random numbers are used, high bandwidth covert
|
||||
channels are possible. See [Schneier] and more recent research. The
|
||||
leakage of an entire DSA private key in only two DSA signatures has
|
||||
been demonstrated. DSA provides security only if trusted
|
||||
implementations, including trusted random number generation, are
|
||||
used.
|
||||
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
Allocation of meaning to values of the T parameter that are not
|
||||
defined herein (i.e., > 8 ) requires an IETF standards actions. It
|
||||
is intended that values unallocated herein be used to cover future
|
||||
extensions of the DSS standard.
|
||||
|
||||
|
||||
|
||||
Copyright, Disclaimer, and Additional IPR Provisions
|
||||
|
||||
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.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 5]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 6]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
|
||||
Signature Standard, 27 January 2000.
|
||||
|
||||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
Informative References
|
||||
|
||||
[RFC 1034] - "Domain names - concepts and facilities", P.
|
||||
Mockapetris, 11/01/1987.
|
||||
|
||||
[RFC 1035] - "Domain names - implementation and specification", P.
|
||||
Mockapetris, 11/01/1987.
|
||||
|
||||
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
|
||||
1999.
|
||||
|
||||
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
|
||||
(DNS)", D. Eastlake 3rd. May 2001.
|
||||
|
||||
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
|
||||
Jones, September 2001.
|
||||
|
||||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
|
||||
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
|
||||
|
||||
[Schneier] - "Applied Cryptography Second Edition: protocols,
|
||||
algorithms, and source code in C" (second edition), Bruce Schneier,
|
||||
1996, John Wiley and Sons, ISBN 0-471-11709-9.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 7]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Labortories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Telephone: +1-508-786-7554(w)
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
Expiration and File Name
|
||||
|
||||
This draft expires in September 2006.
|
||||
|
||||
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 8]
|
||||
|
||||
@@ -1,580 +0,0 @@
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
Expires: September 2006 March 2006
|
||||
|
||||
|
||||
|
||||
|
||||
Storage of Diffie-Hellman Keying Information in the DNS
|
||||
------- -- -------------- ------ ----------- -- --- ---
|
||||
<draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
|
||||
|
||||
|
||||
|
||||
Status of This Document
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Distribution of this document is unlimited. Comments should be sent
|
||||
to the DNS extensions working group mailing list
|
||||
<namedroppers@ops.ietf.org>.
|
||||
|
||||
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/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The standard method for encoding Diffie-Hellman keys in the Domain
|
||||
Name System is specified.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 1]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Acknowledgements
|
||||
|
||||
Part of the format for Diffie-Hellman keys and the description
|
||||
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
|
||||
and Hemma Prafullchandra. In addition, the following persons
|
||||
provided useful comments that were incorporated into the predecessor
|
||||
of this document: Ran Atkinson, Thomas Narten.
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
Status of This Document....................................1
|
||||
Abstract...................................................1
|
||||
|
||||
Acknowledgements...........................................2
|
||||
Table of Contents..........................................2
|
||||
|
||||
1. Introduction............................................3
|
||||
1.1 About This Document....................................3
|
||||
1.2 About Diffie-Hellman...................................3
|
||||
2. Encoding Diffie-Hellman Keying Information..............4
|
||||
3. Performance Considerations..............................5
|
||||
4. IANA Considerations.....................................5
|
||||
5. Security Considerations.................................5
|
||||
Copyright, Disclaimer, and Additional IPR Provisions.......5
|
||||
|
||||
Normative References.......................................7
|
||||
Informative Refences.......................................7
|
||||
|
||||
Author's Address...........................................8
|
||||
Expiration and File Name...................................8
|
||||
|
||||
Appendix A: Well known prime/generator pairs...............9
|
||||
A.1. Well-Known Group 1: A 768 bit prime..................9
|
||||
A.2. Well-Known Group 2: A 1024 bit prime.................9
|
||||
A.3. Well-Known Group 3: A 1536 bit prime................10
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 2]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
similar information [RFC 1034, 1035]. The DNS has been extended to
|
||||
include digital signatures and cryptographic keys as described in
|
||||
[RFC 4033, 4034, 4035] and additonal work is underway which would use
|
||||
the storage of keying information in the DNS.
|
||||
|
||||
|
||||
|
||||
1.1 About This Document
|
||||
|
||||
This document describes how to store Diffie-Hellman keys in the DNS.
|
||||
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
|
||||
[Schneier, RFC 2631].
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
1.2 About Diffie-Hellman
|
||||
|
||||
Diffie-Hellman requires two parties to interact to derive keying
|
||||
information which can then be used for authentication. Thus Diffie-
|
||||
Hellman is inherently a key agreement algorithm. As a result, no
|
||||
format is defined for Diffie-Hellman "signature information". For
|
||||
example, assume that two parties have local secrets "i" and "j".
|
||||
Assume they each respectively calculate X and Y as follows:
|
||||
|
||||
X = g**i ( mod p )
|
||||
|
||||
Y = g**j ( mod p )
|
||||
|
||||
They exchange these quantities and then each calculates a Z as
|
||||
follows:
|
||||
|
||||
Zi = Y**i ( mod p )
|
||||
|
||||
Zj = X**j ( mod p )
|
||||
|
||||
Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
|
||||
secret between the two parties that an adversary who does not know i
|
||||
or j will not be able to learn from the exchanged messages (unless
|
||||
the adversary can derive i or j by performing a discrete logarithm
|
||||
mod p which is hard for strong p and g).
|
||||
|
||||
The private key for each party is their secret i (or j). The public
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 3]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
key is the pair p and g, which is the same for both parties, and
|
||||
their individual X (or Y).
|
||||
|
||||
For further information about Diffie-Hellman and precautions to take
|
||||
in deciding on a p and g, see [RFC 2631].
|
||||
|
||||
|
||||
|
||||
2. Encoding Diffie-Hellman Keying Information
|
||||
|
||||
When Diffie-Hellman keys appear within the RDATA portion of a RR,
|
||||
they are encoded as shown below.
|
||||
|
||||
The period of key validity is not included in this data but is
|
||||
indicated separately, for example by an RR such as RRSIG which signs
|
||||
and authenticates the RR containing the keying information.
|
||||
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| KEY flags | protocol | algorithm=2 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| prime length (or flag) | prime (p) (or special) /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ prime (p) (variable length) | generator length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| generator (g) (variable length) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| public value length | public value (variable length)/
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ public value (g^i mod p) (variable length) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
Prime length is the length of the Diffie-Hellman prime (p) in bytes
|
||||
if it is 16 or greater. Prime contains the binary representation of
|
||||
the Diffie-Hellman prime with most significant byte first (i.e., in
|
||||
network order). If "prime length" field is 1 or 2, then the "prime"
|
||||
field is actually an unsigned index into a table of 65,536
|
||||
prime/generator pairs and the generator length SHOULD be zero. See
|
||||
Appedix A for defined table entries and Section 4 for information on
|
||||
allocating additional table entries. The meaning of a zero or 3
|
||||
through 15 value for "prime length" is reserved.
|
||||
|
||||
Generator length is the length of the generator (g) in bytes.
|
||||
Generator is the binary representation of generator with most
|
||||
significant byte first. PublicValueLen is the Length of the Public
|
||||
Value (g**i (mod p)) in bytes. PublicValue is the binary
|
||||
representation of the DH public value with most significant byte
|
||||
first.
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 4]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
3. Performance Considerations
|
||||
|
||||
Current DNS implementations are optimized for small transfers,
|
||||
typically less than 512 bytes including DNS overhead. Larger
|
||||
transfers will perform correctly and extensions have been
|
||||
standardized [RFC 2671] to make larger transfers more efficient. But
|
||||
it is still advisable at this time to make reasonable efforts to
|
||||
minimize the size of RR sets containing keying information consistent
|
||||
with adequate security.
|
||||
|
||||
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
|
||||
an IETF consensus as defined in [RFC 2434].
|
||||
|
||||
Well known prime/generator pairs number 0x0000 through 0x07FF can
|
||||
only be assigned by an IETF standards action. [RFC 2539], the
|
||||
Proposed Standard predecessor of this document, assigned 0x0001
|
||||
through 0x0002. This document additionally assigns 0x0003. Pairs
|
||||
number 0s0800 through 0xBFFF can be assigned based on RFC
|
||||
documentation. Pairs number 0xC000 through 0xFFFF are available for
|
||||
private use and are not centrally coordinated. Use of such private
|
||||
pairs outside of a closed environment may result in conflicts and/or
|
||||
security failures.
|
||||
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Keying information retrieved from the DNS should not be trusted
|
||||
unless (1) it has been securely obtained from a secure resolver or
|
||||
independently verified by the user and (2) this secure resolver and
|
||||
secure obtainment or independent verification conform to security
|
||||
policies acceptable to the user. As with all cryptographic
|
||||
algorithms, evaluating the necessary strength of the key is important
|
||||
and dependent on security policy.
|
||||
|
||||
In addition, the usual Diffie-Hellman key strength considerations
|
||||
apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
|
||||
SHOULD be "large", etc. See [RFC 2631, Schneier].
|
||||
|
||||
|
||||
|
||||
Copyright, Disclaimer, and Additional IPR Provisions
|
||||
|
||||
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.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 5]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 6]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
|
||||
in RFCs", T. Narten, H. Alvestrand, October 1998.
|
||||
|
||||
[RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
|
||||
1999.
|
||||
|
||||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
Informative Refences
|
||||
|
||||
[RFC 1034] - "Domain names - concepts and facilities", P.
|
||||
Mockapetris, November 1987.
|
||||
|
||||
[RFC 1035] - "Domain names - implementation and specification", P.
|
||||
Mockapetris, November 1987.
|
||||
|
||||
[RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
|
||||
System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
|
||||
|
||||
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
|
||||
1999.
|
||||
|
||||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
|
||||
Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
|
||||
and Sons.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 7]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Telephone: +1-508-786-7554
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
Expiration and File Name
|
||||
|
||||
This draft expires in September 2006.
|
||||
|
||||
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 8]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Appendix A: Well known prime/generator pairs
|
||||
|
||||
These numbers are copied from the IPSEC effort where the derivation
|
||||
of these values is more fully explained and additional information is
|
||||
available. Richard Schroeppel performed all the mathematical and
|
||||
computational work for this appendix.
|
||||
|
||||
|
||||
|
||||
A.1. Well-Known Group 1: A 768 bit prime
|
||||
|
||||
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
|
||||
decimal value is
|
||||
155251809230070893513091813125848175563133404943451431320235
|
||||
119490296623994910210725866945387659164244291000768028886422
|
||||
915080371891804634263272761303128298374438082089019628850917
|
||||
0691316593175367469551763119843371637221007210577919
|
||||
|
||||
Prime modulus: Length (32 bit words): 24, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
A.2. Well-Known Group 2: A 1024 bit prime
|
||||
|
||||
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
|
||||
Its decimal value is
|
||||
179769313486231590770839156793787453197860296048756011706444
|
||||
423684197180216158519368947833795864925541502180565485980503
|
||||
646440548199239100050792877003355816639229553136239076508735
|
||||
759914822574862575007425302077447712589550957937778424442426
|
||||
617334727629299387668709205606050270810842907692932019128194
|
||||
467627007
|
||||
|
||||
Prime modulus: Length (32 bit words): 32, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
|
||||
FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 9]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
A.3. Well-Known Group 3: A 1536 bit prime
|
||||
|
||||
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
|
||||
Its decimal value is
|
||||
241031242692103258855207602219756607485695054850245994265411
|
||||
694195810883168261222889009385826134161467322714147790401219
|
||||
650364895705058263194273070680500922306273474534107340669624
|
||||
601458936165977404102716924945320037872943417032584377865919
|
||||
814376319377685986952408894019557734611984354530154704374720
|
||||
774996976375008430892633929555996888245787241299381012913029
|
||||
459299994792636526405928464720973038494721168143446471443848
|
||||
8520940127459844288859336526896320919633919
|
||||
|
||||
Prime modulus Length (32 bit words): 48, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 10]
|
||||
|
||||
@@ -1,729 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group M. StJohns
|
||||
Internet-Draft Nominum, Inc.
|
||||
Intended status: Informational November 29, 2006
|
||||
Expires: June 2, 2007
|
||||
|
||||
|
||||
Automated Updates of DNSSEC Trust Anchors
|
||||
draft-ietf-dnsext-trustupdate-timers-05
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on June 2, 2007.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a means for automated, authenticated and
|
||||
authorized updating of DNSSEC "trust anchors". The method provides
|
||||
protection against N-1 key compromises of N keys in the trust point
|
||||
key set. Based on the trust established by the presence of a current
|
||||
anchor, other anchors may be added at the same place in the
|
||||
hierarchy, and, ultimately, supplant the existing anchor(s).
|
||||
|
||||
This mechanism will require changes to resolver management behavior
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 1]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
(but not resolver resolution behavior), and the addition of a single
|
||||
flag bit to the DNSKEY record.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
|
||||
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
|
||||
2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
|
||||
2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
|
||||
2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
|
||||
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
|
||||
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8
|
||||
6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
|
||||
6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9
|
||||
6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
|
||||
6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
|
||||
6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
|
||||
6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
|
||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
|
||||
8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
|
||||
8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
|
||||
8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
|
||||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
|
||||
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 13
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 2]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
As part of the reality of fielding DNSSEC (Domain Name System
|
||||
Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
|
||||
come to the realization that there will not be one signed name space,
|
||||
but rather islands of signed name space each originating from
|
||||
specific points (i.e. 'trust points') in the DNS tree. Each of those
|
||||
islands will be identified by the trust point name, and validated by
|
||||
at least one associated public key. For the purpose of this document
|
||||
we'll call the association of that name and a particular key a 'trust
|
||||
anchor'. A particular trust point can have more than one key
|
||||
designated as a trust anchor.
|
||||
|
||||
For a DNSSEC-aware resolver to validate information in a DNSSEC
|
||||
protected branch of the hierarchy, it must have knowledge of a trust
|
||||
anchor applicable to that branch. It may also have more than one
|
||||
trust anchor for any given trust point. Under current rules, a chain
|
||||
of trust for DNSSEC-protected data that chains its way back to ANY
|
||||
known trust anchor is considered 'secure'.
|
||||
|
||||
Because of the probable balkanization of the DNSSEC tree due to
|
||||
signing voids at key locations, a resolver may need to know literally
|
||||
thousands of trust anchors to perform its duties. (e.g. Consider an
|
||||
unsigned ".COM".) Requiring the owner of the resolver to manually
|
||||
manage this many relationships is problematic. It's even more
|
||||
problematic when considering the eventual requirement for key
|
||||
replacement/update for a given trust anchor. The mechanism described
|
||||
herein won't help with the initial configuration of the trust anchors
|
||||
in the resolvers, but should make trust point key replacement/
|
||||
rollover more viable.
|
||||
|
||||
As mentioned above, this document describes a mechanism whereby a
|
||||
resolver can update the trust anchors for a given trust point, mainly
|
||||
without human intervention at the resolver. There are some corner
|
||||
cases discussed (e.g. multiple key compromise) that may require
|
||||
manual intervention, but they should be few and far between. This
|
||||
document DOES NOT discuss the general problem of the initial
|
||||
configuration of trust anchors for the resolver.
|
||||
|
||||
1.1. Compliance Nomenclature
|
||||
|
||||
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 BCP 14, [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 3]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
2. Theory of Operation
|
||||
|
||||
The general concept of this mechanism is that existing trust anchors
|
||||
can be used to authenticate new trust anchors at the same point in
|
||||
the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a
|
||||
DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
|
||||
2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
|
||||
validated by an existing trust anchor, then the resolver can add the
|
||||
new key to its valid set of trust anchors for that trust point.
|
||||
|
||||
There are some issues with this approach which need to be mitigated.
|
||||
For example, a compromise of one of the existing keys could allow an
|
||||
attacker to add their own 'valid' data. This implies a need for a
|
||||
method to revoke an existing key regardless of whether or not that
|
||||
key is compromised. As another example, assuming a single key
|
||||
compromise, we need to prevent an attacker from adding a new key and
|
||||
revoking all the other old keys.
|
||||
|
||||
2.1. Revocation
|
||||
|
||||
Assume two trust anchor keys A and B. Assume that B has been
|
||||
compromised. Without a specific revocation bit, B could invalidate A
|
||||
simply by sending out a signed trust point key set which didn't
|
||||
contain A. To fix this, we add a mechanism which requires knowledge
|
||||
of the private key of a DNSKEY to revoke that DNSKEY.
|
||||
|
||||
A key is considered revoked when the resolver sees the key in a self-
|
||||
signed RRSet and the key has the REVOKE bit (see Section 7 below) set
|
||||
to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this
|
||||
key as a trust anchor or for any other purposes except validating the
|
||||
RRSIG it signed over the DNSKEY RRSet specifically for the purpose of
|
||||
validating the revocation. Unlike the 'Add' operation below,
|
||||
revocation is immediate and permanent upon receipt of a valid
|
||||
revocation at the resolver.
|
||||
|
||||
A self-signed RRSet is a DNSKEY RRSet which contains the specific
|
||||
DNSKEY and for which there is a corresponding validated RRSIG record.
|
||||
It's not a special DNSKEY RRSet, just a way of describing the
|
||||
validation requirements for that RRSet.
|
||||
|
||||
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
|
||||
than one without the bit set. This affects the matching of a DNSKEY
|
||||
to DS records in the parent, or the fingerprint stored at a resolver
|
||||
used to configure a trust point.
|
||||
|
||||
In the given example, the attacker could revoke B because it has
|
||||
knowledge of B's private key, but could not revoke A.
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 4]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
2.2. Add Hold-Down
|
||||
|
||||
Assume two trust point keys A and B. Assume that B has been
|
||||
compromised. An attacker could generate and add a new trust anchor
|
||||
key - C (by adding C to the DNSKEY RRSet and signing it with B), and
|
||||
then invalidate the compromised key. This would result in both the
|
||||
attacker and owner being able to sign data in the zone and have it
|
||||
accepted as valid by resolvers.
|
||||
|
||||
To mitigate but not completely solve this problem, we add a hold-down
|
||||
time to the addition of the trust anchor. When the resolver sees a
|
||||
new SEP key in a validated trust point DNSKEY RRSet, the resolver
|
||||
starts an acceptance timer, and remembers all the keys that validated
|
||||
the RRSet. If the resolver ever sees the DNSKEY RRSet without the
|
||||
new key but validly signed, it stops the acceptance process for that
|
||||
key and resets the acceptance timer. If all of the keys which were
|
||||
originally used to validate this key are revoked prior to the timer
|
||||
expiring, the resolver stops the acceptance process and resets the
|
||||
timer.
|
||||
|
||||
Once the timer expires, the new key will be added as a trust anchor
|
||||
the next time the validated RRSet with the new key is seen at the
|
||||
resolver. The resolver MUST NOT treat the new key as a trust anchor
|
||||
until the hold down time expires AND it has retrieved and validated a
|
||||
DNSKEY RRSet after the hold down time which contains the new key.
|
||||
|
||||
N.B.: Once the resolver has accepted a key as a trust anchor, the key
|
||||
MUST be considered a valid trust anchor by that resolver until
|
||||
explictly revoked as described above.
|
||||
|
||||
In the given example, the zone owner can recover from a compromise by
|
||||
revoking B and adding a new key D and signing the DNSKEY RRSet with
|
||||
both A and B.
|
||||
|
||||
The reason this does not completely solve the problem has to do with
|
||||
the distributed nature of DNS. The resolver only knows what it sees.
|
||||
A determined attacker who holds one compromised key could keep a
|
||||
single resolver from realizing that key had been compromised by
|
||||
intercepting 'real' data from the originating zone and substituting
|
||||
their own (e.g. using the example, signed only by B). This is no
|
||||
worse than the current situation assuming a compromised key.
|
||||
|
||||
2.3. Active Refresh
|
||||
|
||||
A resolver which has been configured for automatic update of keys
|
||||
from a particular trust point MUST query that trust point (e.g. do a
|
||||
lookup for the DNSKEY RRSet and related RRSIG records) no less often
|
||||
than the lesser of 15 days or half the original TTL for the DNSKEY
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 5]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
RRSet or half the RRSIG expiration interval and no more often than
|
||||
once per hour. The expiration interval is the amount of time from
|
||||
when the RRSIG was last retrieved until the expiration time in the
|
||||
RRSIG.
|
||||
|
||||
If the query fails, the resolver MUST repeat the query until
|
||||
satisfied no more often than once an hour and no less often than the
|
||||
lesser of 1 day or 10% of the original TTL or 10% of the original
|
||||
expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
|
||||
origTTL, .1 * expireInterval)).
|
||||
|
||||
2.4. Resolver Parameters
|
||||
|
||||
2.4.1. Add Hold-Down Time
|
||||
|
||||
The add hold-down time is 30 days or the expiration time of the
|
||||
original TTL of the first trust point DNSKEY RRSet which contained
|
||||
the new key, whichever is greater. This ensures that at least two
|
||||
validated DNSKEY RRSets which contain the new key MUST be seen by the
|
||||
resolver prior to the key's acceptance.
|
||||
|
||||
2.4.2. Remove Hold-Down Time
|
||||
|
||||
The remove hold-down time is 30 days. This parameter is solely a key
|
||||
management database bookeeping parameter. Failure to remove
|
||||
information about the state of defunct keys from the database will
|
||||
not adversely impact the security of this protocol, but may end up
|
||||
with a database cluttered with obsolete key information.
|
||||
|
||||
2.4.3. Minimum Trust Anchors per Trust Point
|
||||
|
||||
A compliant resolver MUST be able to manage at least five SEP keys
|
||||
per trust point.
|
||||
|
||||
|
||||
3. Changes to DNSKEY RDATA Wire Format
|
||||
|
||||
Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE'
|
||||
flag. If this bit is set to '1', AND the resolver sees an
|
||||
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
|
||||
consider this key permanently invalid for all purposes except for
|
||||
validating the revocation.
|
||||
|
||||
|
||||
4. State Table
|
||||
|
||||
The most important thing to understand is the resolver's view of any
|
||||
key at a trust point. The following state table describes that view
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 6]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
at various points in the key's lifetime. The table is a normative
|
||||
part of this specification. The initial state of the key is 'Start'.
|
||||
The resolver's view of the state of the key changes as various events
|
||||
occur.
|
||||
|
||||
This is the state of a trust point key as seen from the resolver.
|
||||
The column on the left indicates the current state. The header at
|
||||
the top shows the next state. The intersection of the two shows the
|
||||
event that will cause the state to transition from the current state
|
||||
to the next.
|
||||
|
||||
|
||||
NEXT STATE
|
||||
--------------------------------------------------
|
||||
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
|
||||
----------------------------------------------------------
|
||||
Start | |NewKey | | | | |
|
||||
----------------------------------------------------------
|
||||
AddPend |KeyRem | |AddTime| | |
|
||||
----------------------------------------------------------
|
||||
Valid | | | |KeyRem |Revbit | |
|
||||
----------------------------------------------------------
|
||||
Missing | | |KeyPres| |Revbit | |
|
||||
----------------------------------------------------------
|
||||
Revoked | | | | | |RemTime|
|
||||
----------------------------------------------------------
|
||||
Removed | | | | | | |
|
||||
----------------------------------------------------------
|
||||
|
||||
|
||||
State Table
|
||||
|
||||
4.1. Events
|
||||
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
|
||||
That key will become a new trust anchor for the named trust point
|
||||
after it's been present in the RRSet for at least 'add time'.
|
||||
KeyPres The key has returned to the valid DNSKEY RRSet.
|
||||
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
|
||||
this key.
|
||||
AddTime The key has been in every valid DNSKEY RRSet seen for at
|
||||
least the 'add time'.
|
||||
RemTime A revoked key has been missing from the trust point DNSKEY
|
||||
RRSet for sufficient time to be removed from the trust set.
|
||||
RevBit The key has appeared in the trust anchor DNSKEY RRSet with
|
||||
its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
|
||||
signed by this key.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 7]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
4.2. States
|
||||
Start The key doesn't yet exist as a trust anchor at the resolver.
|
||||
It may or may not exist at the zone server, but either hasn't yet
|
||||
been seen at the resolver or was seen but was absent from the last
|
||||
DNSKEY RRSet (e.g. KeyRem event).
|
||||
AddPend The key has been seen at the resolver, has its 'SEP' bit
|
||||
set, and has been included in a validated DNSKEY RRSet. There is
|
||||
a hold-down time for the key before it can be used as a trust
|
||||
anchor.
|
||||
Valid The key has been seen at the resolver and has been included in
|
||||
all validated DNSKEY RRSets from the time it was first seen up
|
||||
through the hold-down time. It is now valid for verifying RRSets
|
||||
that arrive after the hold down time. Clarification: The DNSKEY
|
||||
RRSet does not need to be continuously present at the resolver
|
||||
(e.g. its TTL might expire). If the RRSet is seen, and is
|
||||
validated (i.e. verifies against an existing trust anchor), this
|
||||
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
|
||||
Missing This is an abnormal state. The key remains as a valid trust
|
||||
point key, but was not seen at the resolver in the last validated
|
||||
DNSKEY RRSet. This is an abnormal state because the zone operator
|
||||
should be using the REVOKE bit prior to removal.
|
||||
Revoked This is the state a key moves to once the resolver sees an
|
||||
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
|
||||
this key with its REVOKE bit set to '1'. Once in this state, this
|
||||
key MUST permanently be considered invalid as a trust anchor.
|
||||
Removed After a fairly long hold-down time, information about this
|
||||
key may be purged from the resolver. A key in the removed state
|
||||
MUST NOT be considered a valid trust anchor. (Note: this state is
|
||||
more or less equivalent to the "Start" state, except that it's bad
|
||||
practice to re-introduce previously used keys - think of this as
|
||||
the holding state for all the old keys for which the resolver no
|
||||
longer needs to track state.)
|
||||
|
||||
|
||||
5. Trust Point Deletion
|
||||
|
||||
A trust point which has all of its trust anchors revoked is
|
||||
considered deleted and is treated as if the trust point was never
|
||||
configured. If there are no superior configured trust points, data
|
||||
at and below the deleted trust point are considered insecure by the
|
||||
resolver. If there ARE superior configured trust points, data at and
|
||||
below the deleted trust point are evaluated with respect to the
|
||||
superior trust point(s).
|
||||
|
||||
Alternately, a trust point which is subordinate to another configured
|
||||
trust point MAY be deleted by a resolver after 180 days where such
|
||||
subordinate trust point validly chains to a superior trust point.
|
||||
The decision to delete the subordinate trust anchor is a local
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 8]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
configuration decision. Once the subordinate trust point is deleted,
|
||||
validation of the subordinate zone is dependent on validating the
|
||||
chain of trust to the superior trust point.
|
||||
|
||||
|
||||
6. Scenarios - Informative
|
||||
|
||||
The suggested model for operation is to have one active key and one
|
||||
stand-by key at each trust point. The active key will be used to
|
||||
sign the DNSKEY RRSet. The stand-by key will not normally sign this
|
||||
RRSet, but the resolver will accept it as a trust anchor if/when it
|
||||
sees the signature on the trust point DNSKEY RRSet.
|
||||
|
||||
Since the stand-by key is not in active signing use, the associated
|
||||
private key may (and should) be provided with additional protections
|
||||
not normally available to a key that must be used frequently. E.g.
|
||||
locked in a safe, split among many parties, etc. Notionally, the
|
||||
stand-by key should be less subject to compromise than an active key,
|
||||
but that will be dependent on operational concerns not addressed
|
||||
here.
|
||||
|
||||
6.1. Adding a Trust Anchor
|
||||
|
||||
Assume an existing trust anchor key 'A'.
|
||||
1. Generate a new key pair.
|
||||
2. Create a DNSKEY record from the key pair and set the SEP and Zone
|
||||
Key bits.
|
||||
3. Add the DNSKEY to the RRSet.
|
||||
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
|
||||
'A'.
|
||||
5. Wait a while (i.e. for various resolvers timers to go off and for
|
||||
them to retrieve the new DNSKEY RRSet and signatures).
|
||||
6. The new trust anchor will be populated at the resolvers on the
|
||||
schedule described by the state table and update algorithm - see
|
||||
Section 2 above
|
||||
|
||||
6.2. Deleting a Trust Anchor
|
||||
|
||||
Assume existing trust anchors 'A' and 'B' and that you want to revoke
|
||||
and delete 'A'.
|
||||
1. Set the revocation bit on key 'A'.
|
||||
2. Sign the DNSKEY RRSet with both 'A' and 'B'.
|
||||
'A' is now revoked. The operator should include the revoked 'A' in
|
||||
the RRSet for at least the remove hold-down time, but then may remove
|
||||
it from the DNSKEY RRSet.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 9]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
6.3. Key Roll-Over
|
||||
|
||||
Assume existing keys A and B. 'A' is actively in use (i.e. has been
|
||||
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
|
||||
in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
|
||||
used to sign the RRSet.)
|
||||
1. Generate a new key pair 'C'.
|
||||
2. Add 'C' to the DNSKEY RRSet.
|
||||
3. Set the revocation bit on key 'A'.
|
||||
4. Sign the RRSet with 'A' and 'B'.
|
||||
'A' is now revoked, 'B' is now the active key, and 'C' will be the
|
||||
stand-by key once the hold-down expires. The operator should include
|
||||
the revoked 'A' in the RRSet for at least the remove hold-down time,
|
||||
but may then remove it from the DNSKEY RRSet.
|
||||
|
||||
6.4. Active Key Compromised
|
||||
|
||||
This is the same as the mechanism for Key Roll-Over (Section 6.3)
|
||||
above assuming 'A' is the active key.
|
||||
|
||||
6.5. Stand-by Key Compromised
|
||||
|
||||
Using the same assumptions and naming conventions as Key Roll-Over
|
||||
(Section 6.3) above:
|
||||
1. Generate a new key pair 'C'.
|
||||
2. Add 'C' to the DNSKEY RRSet.
|
||||
3. Set the revocation bit on key 'B'.
|
||||
4. Sign the RRSet with 'A' and 'B'.
|
||||
'B' is now revoked, 'A' remains the active key, and 'C' will be the
|
||||
stand-by key once the hold-down expires. 'B' should continue to be
|
||||
included in the RRSet for the remove hold-down time.
|
||||
|
||||
6.6. Trust Point Deletion
|
||||
|
||||
To delete a trust point which is subordinate to another configured
|
||||
trust point (e.g. example.com to .com) requires some juggling of the
|
||||
data. The specific process is:
|
||||
1. Generate a new DNSKEY and DS record and provide the DS record to
|
||||
the parent along with DS records for the old keys
|
||||
2. Once the parent has published the DSs, add the new DNSKEY to the
|
||||
RRSet and revoke ALL of the old keys at the same time while
|
||||
signing the DNSKEY RRSet with all of the old and new keys.
|
||||
3. After 30 days stop publishing the old, revoked keys and remove
|
||||
any corresponding DS records in the parent.
|
||||
Revoking the old trust point keys at the same time as adding new keys
|
||||
that chain to a superior trust prevents the resolver from adding the
|
||||
new keys as trust anchors. Adding DS records for the old keys avoids
|
||||
a race condition where either the subordinate zone becomes unsecure
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 10]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
(because the trust point was deleted) or becomes bogus (because it
|
||||
didn't chain to the superior zone).
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
The IANA will need to assign a bit in the DNSKEY flags field (see
|
||||
section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
|
||||
IANA actions required.
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
In addition to the following sections, see also Theory of Operation
|
||||
above and especially Section 2.2 for related discussions.
|
||||
|
||||
8.1. Key Ownership vs Acceptance Policy
|
||||
|
||||
The reader should note that, while the zone owner is responsible for
|
||||
creating and distributing keys, it's wholly the decision of the
|
||||
resolver owner as to whether to accept such keys for the
|
||||
authentication of the zone information. This implies the decision to
|
||||
update trust anchor keys based on trust for a current trust anchor
|
||||
key is also the resolver owner's decision.
|
||||
|
||||
The resolver owner (and resolver implementers) MAY choose to permit
|
||||
or prevent key status updates based on this mechanism for specific
|
||||
trust points. If they choose to prevent the automated updates, they
|
||||
will need to establish a mechanism for manual or other out-of-band
|
||||
updates outside the scope of this document.
|
||||
|
||||
8.2. Multiple Key Compromise
|
||||
|
||||
This scheme permits recovery as long as at least one valid trust
|
||||
anchor key remains uncompromised. E.g. if there are three keys, you
|
||||
can recover if two of them are compromised. The zone owner should
|
||||
determine their own level of comfort with respect to the number of
|
||||
active valid trust anchors in a zone and should be prepared to
|
||||
implement recovery procedures once they detect a compromise. A
|
||||
manual or other out-of-band update of all resolvers will be required
|
||||
if all trust anchor keys at a trust point are compromised.
|
||||
|
||||
8.3. Dynamic Updates
|
||||
|
||||
Allowing a resolver to update its trust anchor set based on in-band
|
||||
key information is potentially less secure than a manual process.
|
||||
However, given the nature of the DNS, the number of resolvers that
|
||||
would require update if a trust anchor key were compromised, and the
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 11]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
lack of a standard management framework for DNS, this approach is no
|
||||
worse than the existing situation.
|
||||
|
||||
|
||||
9. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
|
||||
Signer (DS)", RFC 3755, May 2004.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements",
|
||||
RFC 4033, March 2005.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
Editorial Comments
|
||||
|
||||
[msj2] msj: To be assigned.
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Michael StJohns
|
||||
Nominum, Inc.
|
||||
2385 Bay Road
|
||||
Redwood City, CA 94063
|
||||
USA
|
||||
|
||||
Phone: +1-301-528-4729
|
||||
Email: Mike.StJohns@nominum.com
|
||||
URI: www.nominum.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 12]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 13]
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -1,640 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DNSOP Working Group Paul Vixie, ISC
|
||||
INTERNET-DRAFT Akira Kato, WIDE
|
||||
<draft-ietf-dnsop-respsize-06.txt> August 2006
|
||||
|
||||
DNS Referral Response Size Issues
|
||||
|
||||
Status of this Memo
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006). All Rights Reserved.
|
||||
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
With a mandated default minimum maximum message size of 512 octets,
|
||||
the DNS protocol presents some special problems for zones wishing to
|
||||
expose a moderate or high number of authority servers (NS RRs). This
|
||||
document explains the operational issues caused by, or related to
|
||||
this response size limit, and suggests ways to optimize the use of
|
||||
this limited space. Guidance is offered to DNS server implementors
|
||||
and to DNS zone operators.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 1]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
1 - Introduction and Overview
|
||||
|
||||
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
|
||||
octets. Even though this limitation was due to the required minimum IP
|
||||
reassembly limit for IPv4, it became a hard DNS protocol limit and is
|
||||
not implicitly relaxed by changes in transport, for example to IPv6.
|
||||
|
||||
1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
|
||||
larger responses by mutual agreement of the requester and responder.
|
||||
The 512 octet message size limit will remain in practical effect until
|
||||
there is widespread deployment of EDNS0 in DNS resolvers on the
|
||||
Internet.
|
||||
|
||||
1.3. Since DNS responses include a copy of the request, the space
|
||||
available for response data is somewhat less than the full 512 octets.
|
||||
Negative responses are quite small, but for positive and delegation
|
||||
responses, every octet must be carefully and sparingly allocated. This
|
||||
document specifically addresses delegation response sizes.
|
||||
|
||||
2 - Delegation Details
|
||||
|
||||
2.1. RELEVANT PROTOCOL ELEMENTS
|
||||
|
||||
2.1.1. A delegation response will include the following elements:
|
||||
|
||||
Header Section: fixed length (12 octets)
|
||||
Question Section: original query (name, class, type)
|
||||
Answer Section: empty, or a CNAME/DNAME chain
|
||||
Authority Section: NS RRset (nameserver names)
|
||||
Additional Section: A and AAAA RRsets (nameserver addresses)
|
||||
|
||||
2.1.2. If the total response size exceeds 512 octets, and if the data
|
||||
that does not fit was "required", then the TC bit will be set
|
||||
(indicating truncation). This will usually cause the requester to retry
|
||||
using TCP, depending on what information was desired and what
|
||||
information was omitted. For example, truncation in the authority
|
||||
section is of no interest to a stub resolver who only plans to consume
|
||||
the answer section. If a retry using TCP is needed, the total cost of
|
||||
the transaction is much higher. See [RFC1123 6.1.3.2] for details on
|
||||
the requirement that UDP be attempted before falling back to TCP.
|
||||
|
||||
2.1.3. RRsets are never sent partially unless TC bit set to indicate
|
||||
truncation. When TC bit is set, the final apparent RRset in the final
|
||||
non-empty section must be considered "possibly damaged" (see [RFC1035
|
||||
6.2], [RFC2181 9]).
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 2]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
2.1.4. With or without truncation, the glue present in the additional
|
||||
data section should be considered "possibly incomplete", and requesters
|
||||
should be prepared to re-query for any damaged or missing RRsets. Note
|
||||
that truncation of the additional data section might not be signalled
|
||||
via the TC bit since additional data is often optional (see discussion
|
||||
in [RFC4472 B]).
|
||||
|
||||
2.1.5. DNS label compression allows a domain name to be instantiated
|
||||
only once per DNS message, and then referenced with a two-octet
|
||||
"pointer" from other locations in that same DNS message (see [RFC1035
|
||||
4.1.4]). If all nameserver names in a message share a common parent
|
||||
(for example, all ending in ".ROOT-SERVERS.NET"), then more space will
|
||||
be available for incompressable data (such as nameserver addresses).
|
||||
|
||||
2.1.6. The query name can be as long as 255 octets of network data. In
|
||||
this worst case scenario, the question section will be 259 octets in
|
||||
size, which would leave only 240 octets for the authority and additional
|
||||
sections (after deducting 12 octets for the fixed length header.)
|
||||
|
||||
2.2. ADVICE TO ZONE OWNERS
|
||||
|
||||
2.2.1. Average and maximum question section sizes can be predicted by
|
||||
the zone owner, since they will know what names actually exist, and can
|
||||
measure which ones are queried for most often. Note that if the zone
|
||||
contains any wildcards, it is possible for maximum length queries to
|
||||
require positive responses, but that it is reasonable to expect
|
||||
truncation and TCP retry in that case. For cost and performance
|
||||
reasons, the majority of requests should be satisfied without truncation
|
||||
or TCP retry.
|
||||
|
||||
2.2.2. Some queries to non-existing names can be large, but this is not
|
||||
a problem because negative responses need not contain any answer,
|
||||
authority or additional records. See [RFC2308 2.1] for more information
|
||||
about the format of negative responses.
|
||||
|
||||
2.2.3. The minimum useful number of name servers is two, for redundancy
|
||||
(see [RFC1034 4.1]). A zone's name servers should be reachable by all
|
||||
IP transport protocols (e.g., IPv4 and IPv6) in common use.
|
||||
|
||||
2.2.4. The best case is no truncation at all. This is because many
|
||||
requesters will retry using TCP immediately, or will automatically re-
|
||||
query for RRsets that are possibly truncated, without considering
|
||||
whether the omitted data was actually necessary.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 3]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
2.3. ADVICE TO SERVER IMPLEMENTORS
|
||||
|
||||
2.3.1. In case of multi-homed name servers, it is advantageous to
|
||||
include an address record from each of several name servers before
|
||||
including several address records for any one name server. If address
|
||||
records for more than one transport (for example, A and AAAA) are
|
||||
available, then it is advantageous to include records of both types
|
||||
early on, before the message is full.
|
||||
|
||||
2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
|
||||
class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
|
||||
Each A RR will require 16 octets, and each AAAA RR will require 28
|
||||
octets.
|
||||
|
||||
2.3.3. While DNS distinguishes between necessary and optional resource
|
||||
records, this distinction is according to protocol elements necessary to
|
||||
signify facts, and takes no official notice of protocol content
|
||||
necessary to ensure correct operation. For example, a nameserver name
|
||||
that is in or below the zone cut being described by a delegation is
|
||||
"necessary content," since there is no way to reach that zone unless the
|
||||
parent zone's delegation includes "glue records" describing that name
|
||||
server's addresses.
|
||||
|
||||
2.3.4. It is also necessary to distinguish between "explicit truncation"
|
||||
where a message could not contain enough records to convey its intended
|
||||
meaning, and so the TC bit has been set, and "silent truncation", where
|
||||
the message was not large enough to contain some records which were "not
|
||||
required", and so the TC bit was not set.
|
||||
|
||||
2.3.5. A delegation response should prioritize glue records as follows.
|
||||
|
||||
first
|
||||
All glue RRsets for one name server whose name is in or below the
|
||||
zone being delegated, or which has multiple address RRsets (currently
|
||||
A and AAAA), or preferably both;
|
||||
|
||||
second
|
||||
Alternate between adding all glue RRsets for any name servers whose
|
||||
names are in or below the zone being delegated, and all glue RRsets
|
||||
for any name servers who have multiple address RRsets (currently A
|
||||
and AAAA);
|
||||
|
||||
thence
|
||||
All other glue RRsets, in any order.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 4]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
Whenever there are multiple candidates for a position in this priority
|
||||
scheme, one should be chosen on a round-robin or fully random basis.
|
||||
|
||||
The goal of this priority scheme is to offer "necessary" glue first,
|
||||
avoiding silent truncation for this glue if possible.
|
||||
|
||||
2.3.6. If any "necessary content" is silently truncated, then it is
|
||||
advisable that the TC bit be set in order to force a TCP retry, rather
|
||||
than have the zone be unreachable. Note that a parent server's proper
|
||||
response to a query for in-child glue or below-child glue is a referral
|
||||
rather than an answer, and that this referral MUST be able to contain
|
||||
the in-child or below-child glue, and that in outlying cases, only EDNS
|
||||
or TCP will be large enough to contain that data.
|
||||
|
||||
3 - Analysis
|
||||
|
||||
3.1. An instrumented protocol trace of a best case delegation response
|
||||
follows. Note that 13 servers are named, and 13 addresses are given.
|
||||
This query was artificially designed to exactly reach the 512 octet
|
||||
limit.
|
||||
|
||||
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
|
||||
;; QUERY SECTION:
|
||||
;; [23456789.123456789.123456789.\
|
||||
123456789.123456789.123456789.com A IN] ;; @80
|
||||
|
||||
;; AUTHORITY SECTION:
|
||||
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
|
||||
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
|
||||
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
|
||||
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
|
||||
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
|
||||
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
|
||||
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
|
||||
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
|
||||
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
|
||||
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
|
||||
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
|
||||
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
|
||||
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 5]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
|
||||
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
|
||||
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
|
||||
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
|
||||
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
|
||||
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
|
||||
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
|
||||
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
|
||||
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
|
||||
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
|
||||
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
|
||||
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
|
||||
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
|
||||
|
||||
;; MSG SIZE sent: 80 rcvd: 512
|
||||
|
||||
3.2. For longer query names, the number of address records supplied will
|
||||
be lower. Furthermore, it is only by using a common parent name (which
|
||||
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
|
||||
fit, due to the use of DNS compression pointers in the last 12
|
||||
occurances of the parent domain name. The following output from a
|
||||
response simulator demonstrates these properties.
|
||||
|
||||
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
|
||||
a.dns.br requires 10 bytes
|
||||
b.dns.br requires 4 bytes
|
||||
c.dns.br requires 4 bytes
|
||||
d.dns.br requires 4 bytes
|
||||
# of NS: 4
|
||||
For maximum size query (255 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 3 (yellow)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
|
||||
For average size query (64 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 4 (green)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 6]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
|
||||
ns-ext.isc.org requires 16 bytes
|
||||
ns.psg.com requires 12 bytes
|
||||
ns.ripe.net requires 13 bytes
|
||||
ns.eu.int requires 11 bytes
|
||||
# of NS: 4
|
||||
For maximum size query (255 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 3 (yellow)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
|
||||
For average size query (64 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 4 (green)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
|
||||
|
||||
(Note: The response simulator program is shown in Section 5.)
|
||||
|
||||
Here we use the term "green" if all address records could fit, or
|
||||
"yellow" if two or more could fit, or "orange" if only one could fit, or
|
||||
"red" if no address record could fit. It's clear that without a common
|
||||
parent for nameserver names, much space would be lost. For these
|
||||
examples we use an average/common name size of 15 octets, befitting our
|
||||
assumption of GTLD-SERVERS.NET as our common parent name.
|
||||
|
||||
We're assuming a medium query name size of 64 since that is the typical
|
||||
size seen in trace data at the time of this writing. If
|
||||
Internationalized Domain Name (IDN) or any other technology which
|
||||
results in larger query names be deployed significantly in advance of
|
||||
EDNS, then new measurements and new estimates will have to be made.
|
||||
|
||||
4 - Conclusions
|
||||
|
||||
4.1. The current practice of giving all nameserver names a common parent
|
||||
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
|
||||
responses and allows for more nameservers to be enumerated than would
|
||||
otherwise be possible, since the common parent domain name only appears
|
||||
once in a DNS message and is referred to via "compression pointers"
|
||||
thereafter.
|
||||
|
||||
4.2. If all nameserver names for a zone share a common parent, then it
|
||||
is operationally advisable to make all servers for the zone thus served
|
||||
also be authoritative for the zone of that common parent. For example,
|
||||
the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
|
||||
for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
|
||||
always have the zone's nameservers' glue available when delegating, and
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 7]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
will be able to respond with answers rather than referrals if a
|
||||
requester who wants that glue comes back asking for it. In this case
|
||||
the name server will likely be a "stealth server" -- authoritative but
|
||||
unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
|
||||
information about stealth servers.
|
||||
|
||||
4.3. Thirteen (13) is the effective maximum number of nameserver names
|
||||
usable traditional (non-extended) DNS, assuming a common parent domain
|
||||
name, and given that implicit referral response truncation is
|
||||
undesirable in the average case.
|
||||
|
||||
4.4. Multi-homing of name servers within a protocol family is
|
||||
inadvisable since the necessary glue RRsets (A or AAAA) are atomically
|
||||
indivisible, and will be larger than a single resource record. Larger
|
||||
RRsets are more likely to lead to or encounter truncation.
|
||||
|
||||
4.5. Multi-homing of name servers across protocol families is less
|
||||
likely to lead to or encounter truncation, partly because multiprotocol
|
||||
clients are more likely to speak EDNS which can use a larger response
|
||||
size limit, and partly because the resource records (A and AAAA) are in
|
||||
different RRsets and are therefore divisible from each other.
|
||||
|
||||
4.6. Name server names which are at or below the zone they serve are
|
||||
more sensitive to referral response truncation, and glue records for
|
||||
them should be considered "less optional" than other glue records, in
|
||||
the assembly of referral responses.
|
||||
|
||||
4.7. If a zone is served by thirteen (13) name servers having a common
|
||||
parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
|
||||
single address record in some protocol family (e.g., an A RR), then all
|
||||
thirteen name servers or any subset thereof could multi-home in a second
|
||||
protocol family by adding a second address record (e.g., an AAAA RR)
|
||||
without reducing the reachability of the zone thus served.
|
||||
|
||||
5 - Source Code
|
||||
|
||||
#!/usr/bin/perl
|
||||
#
|
||||
# SYNOPSIS
|
||||
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
|
||||
# if all queries are assumed to have a same zone suffix,
|
||||
# such as "jp" in JP TLD servers, specify it in -z option
|
||||
#
|
||||
use strict;
|
||||
use Getopt::Std;
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 8]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
my ($sz_msg) = (512);
|
||||
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
|
||||
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
|
||||
my (%namedb, $name, $nssect, %opts, $optz);
|
||||
my $n_ns = 0;
|
||||
|
||||
getopt('z', %opts);
|
||||
if (defined($opts{'z'})) {
|
||||
server_name_len($opts{'z'}); # just register it
|
||||
}
|
||||
|
||||
foreach $name (@ARGV) {
|
||||
my $len;
|
||||
$n_ns++;
|
||||
$len = server_name_len($name);
|
||||
print "$name requires $len bytes\n";
|
||||
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
|
||||
+ $sz_rdlen + $len;
|
||||
}
|
||||
print "# of NS: $n_ns\n";
|
||||
arsect(255, $nssect, $n_ns, "maximum");
|
||||
arsect(64, $nssect, $n_ns, "average");
|
||||
|
||||
sub server_name_len {
|
||||
my ($name) = @_;
|
||||
my (@labels, $len, $n, $suffix);
|
||||
|
||||
$name =~ tr/A-Z/a-z/;
|
||||
@labels = split(/\./, $name);
|
||||
$len = length(join('.', @labels)) + 2;
|
||||
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
|
||||
$suffix = join('.', @labels);
|
||||
return length($name) - length($suffix) + $sz_ptr
|
||||
if (defined($namedb{$suffix}));
|
||||
$namedb{$suffix} = 1;
|
||||
}
|
||||
return $len;
|
||||
}
|
||||
|
||||
sub arsect {
|
||||
my ($sz_query, $nssect, $n_ns, $cond) = @_;
|
||||
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
|
||||
$ansect = $sz_query + 1 + $sz_type + $sz_class;
|
||||
$space = $sz_msg - $sz_header - $ansect - $nssect;
|
||||
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 9]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
$n_a_aaaa = atmost(int($space
|
||||
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
|
||||
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
|
||||
/ $sz_rr_aaaa), $n_ns);
|
||||
printf "For %s size query (%d byte):\n", $cond, $sz_query;
|
||||
printf " only A is considered: ";
|
||||
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
|
||||
printf " A and AAAA are considered: ";
|
||||
printf "# of A+AAAA is %d (%s)\n",
|
||||
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
|
||||
printf " preferred-glue A is assumed: ";
|
||||
printf "# of A is %d, # of AAAA is %d (%s)\n",
|
||||
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
|
||||
}
|
||||
|
||||
sub judge {
|
||||
my ($n, $n_ns) = @_;
|
||||
return "green" if ($n >= $n_ns);
|
||||
return "yellow" if ($n >= 2);
|
||||
return "orange" if ($n == 1);
|
||||
return "red";
|
||||
}
|
||||
|
||||
sub atmost {
|
||||
my ($a, $b) = @_;
|
||||
return 0 if ($a < 0);
|
||||
return $b if ($a > $b);
|
||||
return $a;
|
||||
}
|
||||
|
||||
6 - Security Considerations
|
||||
|
||||
The recommendations contained in this document have no known security
|
||||
implications.
|
||||
|
||||
7 - IANA Considerations
|
||||
|
||||
This document does not call for changes or additions to any IANA
|
||||
registry.
|
||||
|
||||
8 - Acknowledgement
|
||||
|
||||
The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
|
||||
for their valuable comments and suggestions.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 10]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
This work was supported by the US National Science Foundation (research
|
||||
grant SCI-0427144) and DNS-OARC.
|
||||
|
||||
9 - References
|
||||
|
||||
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
|
||||
RFC1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and
|
||||
Specification", RFC1035, November 1987.
|
||||
|
||||
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
|
||||
Application and Support", RFC1123, October 1989.
|
||||
|
||||
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
|
||||
Changes (DNS NOTIFY)", RFC1996, August 1996.
|
||||
|
||||
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
|
||||
RFC2181, July 1997.
|
||||
|
||||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
|
||||
RFC2308, March 1998.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
|
||||
August 1999.
|
||||
|
||||
[RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
|
||||
and Issues with IPV6 DNS", April 2006.
|
||||
|
||||
10 - Authors' Addresses
|
||||
|
||||
Paul Vixie
|
||||
Internet Systems Consortium, Inc.
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
+1 650 423 1301
|
||||
vixie@isc.org
|
||||
|
||||
Akira Kato
|
||||
University of Tokyo, Information Technology Center
|
||||
2-11-16 Yayoi Bunkyo
|
||||
Tokyo 113-8658, JAPAN
|
||||
+81 3 5841 2750
|
||||
kato@wide.ad.jp
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 11]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors retain
|
||||
all their rights.
|
||||
|
||||
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 provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 12]
|
||||
|
||||
|
||||
@@ -1,618 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Woolf
|
||||
Internet-Draft Internet Systems Consortium, Inc.
|
||||
Expires: September 6, 2006 D. Conrad
|
||||
Nominum, Inc.
|
||||
March 5, 2006
|
||||
|
||||
|
||||
Requirements for a Mechanism Identifying a Name Server Instance
|
||||
draft-ietf-dnsop-serverid-06
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on September 6, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
With the increased use of DNS anycast, load balancing, and other
|
||||
mechanisms allowing more than one DNS name server to share a single
|
||||
IP address, it is sometimes difficult to tell which of a pool of name
|
||||
servers has answered a particular query. A standardized mechanism to
|
||||
determine the identity of a name server responding to a particular
|
||||
query would be useful, particularly as a diagnostic aid for
|
||||
administrators. Existing ad hoc mechanisms for addressing this need
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 1]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
have some shortcomings, not the least of which is the lack of prior
|
||||
analysis of exactly how such a mechanism should be designed and
|
||||
deployed. This document describes the existing convention used in
|
||||
some widely deployed implementations of the DNS protocol, including
|
||||
advantages and disadvantages, and discusses some attributes of an
|
||||
improved mechanism.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 2]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
1. Introduction and Rationale
|
||||
|
||||
Identifying which name server is responding to queries is often
|
||||
useful, particularly in attempting to diagnose name server
|
||||
difficulties. This is most obviously useful for authoritative
|
||||
nameservers in the attempt to diagnose the source or prevalence of
|
||||
inaccurate data, but can also conceivably be useful for caching
|
||||
resolvers in similar and other situations. Furthermore, the ability
|
||||
to identify which server is responding to a query has become more
|
||||
useful as DNS has become more critical to more Internet users, and as
|
||||
network and server deployment topologies have become more complex.
|
||||
|
||||
The traditional means for determining which of several possible
|
||||
servers is answering a query has traditionally been based on the use
|
||||
of the server's IP address as a unique identifier. However, the
|
||||
modern Internet has seen the deployment of various load balancing,
|
||||
fault-tolerance, or attack-resistance schemes such as shared use of
|
||||
unicast IP addresses as documented in [RFC3258]. An unfortunate side
|
||||
effect of these schemes has been to make the use of IP addresses as
|
||||
identifiers somewhat problematic. Specifically, a dedicated DNS
|
||||
query may not go to the same server as answered a previous query,
|
||||
even though sent to the same IP address. Non-DNS methods such as
|
||||
ICMP ping, TCP connections, or non-DNS UDP packets (such as those
|
||||
generated by tools like "traceroute"), etc., may well be even less
|
||||
certain to reach the same server as the one which receives the DNS
|
||||
queries.
|
||||
|
||||
There is a well-known and frequently-used technique for determining
|
||||
an identity for a nameserver more specific than the possibly-non-
|
||||
unique "server that answered the query I sent to IP address XXX".
|
||||
The widespread use of the existing convention suggests a need for a
|
||||
documented, interoperable means of querying the identity of a
|
||||
nameserver that may be part of an anycast or load-balancing cluster.
|
||||
At the same time, however, it also has some drawbacks that argue
|
||||
against standardizing it as it's been practiced so far.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 3]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
2. Existing Conventions
|
||||
|
||||
For some time, the commonly deployed Berkeley Internet Name Domain
|
||||
implementation of the DNS protocol suite from the Internet Systems
|
||||
Consortium [BIND] has supported a way of identifying a particular
|
||||
server via the use of a standards-compliant, if somewhat unusual, DNS
|
||||
query. Specifically, a query to a recent BIND server for a TXT
|
||||
resource record in class 3 (CHAOS) for the domain name
|
||||
"HOSTNAME.BIND." will return a string that can be configured by the
|
||||
name server administrator to provide a unique identifier for the
|
||||
responding server. (The value defaults to the result of a
|
||||
gethostname() call). This mechanism, which is an extension of the
|
||||
BIND convention of using CHAOS class TXT RR queries to sub-domains of
|
||||
the "BIND." domain for version information, has been copied by
|
||||
several name server vendors.
|
||||
|
||||
A refinement to the BIND-based mechanism, which dropped the
|
||||
implementation-specific string, replaces ".BIND" with ".SERVER".
|
||||
Thus the query string to learn the unique name of a server may be
|
||||
queried as "ID.SERVER".
|
||||
|
||||
(For reference, the other well-known name used by recent versions of
|
||||
BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
|
||||
query for a CHAOS TXT RR for this name will return an
|
||||
administratively defined string which defaults to the version of the
|
||||
server responding. This is, however, not generally implemented by
|
||||
other vendors.)
|
||||
|
||||
2.1. Advantages
|
||||
|
||||
There are several valuable attributes to this mechanism, which
|
||||
account for its usefulness.
|
||||
|
||||
1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
|
||||
within the DNS protocol itself. An identification mechanism that
|
||||
relies on the DNS protocol is more likely to be successful
|
||||
(although not guaranteed) in going to the same system as a
|
||||
"normal" DNS query.
|
||||
|
||||
2. Since the identity information is requested and returned within
|
||||
the DNS protocol, it doesn't require allowing any other query
|
||||
mechanism to the server, such as holes in firewalls for
|
||||
otherwise-unallowed ICMP Echo requests. Thus it is likely to
|
||||
reach the same server over a path subject to the same routing,
|
||||
resource, and security policy as the query, without any special
|
||||
exceptions to site security policy.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 4]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
3. It is simple to configure. An administrator can easily turn on
|
||||
this feature and control the results of the relevant query.
|
||||
|
||||
4. It allows the administrator complete control of what information
|
||||
is given out in the response, minimizing passive leakage of
|
||||
implementation or configuration details. Such details are often
|
||||
considered sensitive by infrastructure operators.
|
||||
|
||||
5. Hypothetically, since it's an ordinary DNS record and the
|
||||
relevant DNSSEC RRs are class independent, the id.server response
|
||||
RR could be signed, which has the advantages described in
|
||||
[RFC4033].
|
||||
|
||||
2.2. Disadvantages
|
||||
|
||||
At the same time, there are some serious drawbacks to the CHAOS/TXT
|
||||
query mechanism that argue against standardizing it as it currently
|
||||
operates.
|
||||
|
||||
1. It requires an additional query to correlate between the answer
|
||||
to a DNS query under normal conditions and the supposed identity
|
||||
of the server receiving the query. There are a number of
|
||||
situations in which this simply isn't reliable.
|
||||
|
||||
2. It reserves an entire class in the DNS (CHAOS) for what amounts
|
||||
to one zone. While CHAOS class is defined in [RFC1034] and
|
||||
[RFC1035], it's not clear that supporting it solely for this
|
||||
purpose is a good use of the namespace or of implementation
|
||||
effort.
|
||||
|
||||
3. The initial and still common form, using .BIND, is implementation
|
||||
specific. BIND is one DNS implementation. At the time of this
|
||||
writing, it is probably the most prevalent for authoritative
|
||||
servers. This does not justify standardizing on its ad hoc
|
||||
solution to a problem shared across many operators and
|
||||
implementors. Meanwhile, the proposed refinement changes the
|
||||
string but preserves the ad hoc CHAOS/TXT mechanism.
|
||||
|
||||
4. There is no convention or shared understanding of what
|
||||
information an answer to such a query for a server identity could
|
||||
or should include, including a possible encoding or
|
||||
authentication mechanism.
|
||||
|
||||
The first of the listed disadvantages may be technically the most
|
||||
serious. It argues for an attempt to design a good answer to the
|
||||
problem that "I need to know what nameserver is answering my
|
||||
queries", not simply a convenient one.
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 5]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
2.3. Characteristics of an Implementation Neutral Convention
|
||||
|
||||
The discussion above of advantages and disadvantages to the
|
||||
HOSTNAME.BIND mechanism suggest some requirements for a better
|
||||
solution to the server identification problem. These are summarized
|
||||
here as guidelines for any effort to provide appropriate protocol
|
||||
extensions:
|
||||
|
||||
1. The mechanism adopted must be in-band for the DNS protocol. That
|
||||
is, it needs to allow the query for the server's identifying
|
||||
information to be part of a normal, operational query. It should
|
||||
also permit a separate, dedicated query for the server's
|
||||
identifying information. But it should preserve the ability of
|
||||
the CHAOS/TXT query-based mechanism to work through firewalls and
|
||||
in other situations where only DNS can be relied upon to reach
|
||||
the server of interest.
|
||||
|
||||
2. The new mechanism should not require dedicated namespaces or
|
||||
other reserved values outside of the existing protocol mechanisms
|
||||
for these, i.e. the OPT pseudo-RR. In particular, it should not
|
||||
propagate the existing drawback of requiring support for a CLASS
|
||||
and top level domain in the authoritative server (or the querying
|
||||
tool) to be useful.
|
||||
|
||||
3. Support for the identification functionality should be easy to
|
||||
implement and easy to enable. It must be easy to disable and
|
||||
should lend itself to access controls on who can query for it.
|
||||
|
||||
4. It should be possible to return a unique identifier for a server
|
||||
without requiring the exposure of information that may be non-
|
||||
public and considered sensitive by the operator, such as a
|
||||
hostname or unicast IP address maintained for administrative
|
||||
purposes.
|
||||
|
||||
5. It should be possible to authenticate the received data by some
|
||||
mechanism analogous to those provided by DNSSEC. In this
|
||||
context, the need could be met by including encryption options in
|
||||
the specification of a new mechanism.
|
||||
|
||||
6. The identification mechanism should not be implementation-
|
||||
specific.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 6]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
3. IANA Considerations
|
||||
|
||||
This document proposes no specific IANA action. Protocol extensions,
|
||||
if any, to meet the requirements described are out of scope for this
|
||||
document. A proposed extension, specified and adopted by normal IETF
|
||||
process, is described in [NSID], including relevant IANA action.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 7]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
Providing identifying information as to which server is responding to
|
||||
a particular query from a particular location in the Internet can be
|
||||
seen as information leakage and thus a security risk. This motivates
|
||||
the suggestion above that a new mechanism for server identification
|
||||
allow the administrator to disable the functionality altogether or
|
||||
partially restrict availability of the data. It also suggests that
|
||||
the serverid data should not be readily correlated with a hostname or
|
||||
unicast IP address that may be considered private to the nameserver
|
||||
operator's management infrastructure.
|
||||
|
||||
Propagation of protocol or service meta-data can sometimes expose the
|
||||
application to denial of service or other attack. As DNS is a
|
||||
critically important infrastructure service for the production
|
||||
Internet, extra care needs to be taken against this risk for
|
||||
designers, implementors, and operators of a new mechanism for server
|
||||
identification.
|
||||
|
||||
Both authentication and confidentiality of serverid data are
|
||||
potentially of interest to administrators-- that is, operators may
|
||||
wish to make serverid data available and reliable to themselves and
|
||||
their chosen associates only. This would imply both an ability to
|
||||
authenticate it to themselves and keep it private from arbitrary
|
||||
other parties. This led to Characteristics 4 and 5 of an improved
|
||||
solution.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 8]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
5. Acknowledgements
|
||||
|
||||
The technique for host identification documented here was initially
|
||||
implemented by Paul Vixie of the Internet Software Consortium in the
|
||||
Berkeley Internet Name Daemon package. Comments and questions on
|
||||
earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
|
||||
Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
|
||||
ICANN Root Server System Advisory Committee. The newest version
|
||||
takes a significantly different direction from previous versions,
|
||||
owing to discussion among contributors to the DNSOP working group and
|
||||
others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
|
||||
Weiler, and Rob Austein.
|
||||
|
||||
6. References
|
||||
|
||||
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||||
RFC 1034, STD 0013, November 1987.
|
||||
|
||||
[2] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specification", RFC 1035, STD 0013, November 1987.
|
||||
|
||||
[3] Hardie, T., "Distributing Authoritative Name Servers via Shared
|
||||
Unicast Addresses", RFC 3258, April 2002.
|
||||
|
||||
[4] ISC, "BIND 9 Configuration Reference".
|
||||
|
||||
[5] Austein, S., "DNS Name Server Identifier Option (NSID)",
|
||||
Internet Drafts http://www.ietf.org/internet-drafts/
|
||||
draft-ietf-dnsext-nsid-01.txt, January 2006.
|
||||
|
||||
[6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 9]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Suzanne Woolf
|
||||
Internet Systems Consortium, Inc.
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
US
|
||||
|
||||
Phone: +1 650 423-1333
|
||||
Email: woolf@isc.org
|
||||
URI: http://www.isc.org/
|
||||
|
||||
|
||||
David Conrad
|
||||
Nominum, Inc.
|
||||
2385 Bay Road
|
||||
Redwood City, CA 94063
|
||||
US
|
||||
|
||||
Phone: +1 1 650 381 6003
|
||||
Email: david.conrad@nominum.com
|
||||
URI: http://www.nominum.com/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 10]
|
||||
|
||||
Internet-Draft Serverid March 2006
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Woolf & Conrad Expires September 6, 2006 [Page 11]
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
/*
|
||||
* Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
|
||||
* Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
|
||||
* Copyright (C) 1999-2003 Internet Software Consortium.
|
||||
*
|
||||
* Permission to use, copy, modify, and/or distribute this software for any
|
||||
@@ -15,7 +15,7 @@
|
||||
* PERFORMANCE OF THIS SOFTWARE.
|
||||
*/
|
||||
|
||||
/* $Id: adb.c,v 1.181.2.11.2.30 2007/09/11 02:22:36 marka Exp $ */
|
||||
/* $Id: adb.c,v 1.181.2.11.2.34 2008/04/03 06:07:11 tbox Exp $ */
|
||||
|
||||
/*
|
||||
* Implementation notes
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
* PERFORMANCE OF THIS SOFTWARE.
|
||||
*/
|
||||
|
||||
/* $Id: rbt.c,v 1.115.2.2.2.15 2008/01/22 23:26:40 tbox Exp $ */
|
||||
/* $Id: rbt.c,v 1.115.2.2.2.17 2008/04/03 00:17:07 each Exp $ */
|
||||
|
||||
/* Principal Authors: DCL */
|
||||
|
||||
|
||||
@@ -1133,7 +1133,7 @@
|
||||
./doc/arm/Bv9ARM.ch08.html X 2000,2001,2002,2003,2004,2005,2006,2007,2008
|
||||
./doc/arm/Bv9ARM.ch09.html X 2000,2001,2002,2003,2004,2005,2006,2007,2008
|
||||
./doc/arm/Bv9ARM.html X 2000,2001,2002,2003,2004,2005,2006,2007,2008
|
||||
./doc/arm/Bv9ARM.pdf X 2005,2006
|
||||
./doc/arm/Bv9ARM.pdf X 2005,2006,2008
|
||||
./doc/arm/Makefile.in MAKE 2001,2002,2003,2004,2005,2007
|
||||
./doc/arm/README-SGML TXT.BRIEF 2000,2001,2004
|
||||
./doc/arm/latex-fixup.pl PERL 2005
|
||||
@@ -1648,7 +1648,7 @@
|
||||
./lib/dns/.cvsignore X 1998,1999,2000,2001
|
||||
./lib/dns/Makefile.in MAKE 1998,1999,2000,2001,2002,2003,2004,2006
|
||||
./lib/dns/acl.c C 1999,2000,2001,2002,2003,2004,2006,2007
|
||||
./lib/dns/adb.c C 1999,2000,2001,2002,2003,2004,2005,2006,2007
|
||||
./lib/dns/adb.c C 1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
|
||||
./lib/dns/api X 1999,2000,2001,2002,2003,2004,2005,2006,2007,2008
|
||||
./lib/dns/byaddr.c C 2000,2001,2002,2003,2004
|
||||
./lib/dns/cache.c C 1999,2000,2001,2002,2003,2004,2005,2006
|
||||
|
||||
6
version
6
version
@@ -1,4 +1,4 @@
|
||||
# $Id: version,v 1.26.2.17.2.30 2008/03/04 01:00:07 each Exp $
|
||||
# $Id: version,v 1.26.2.17.2.31 2008/04/03 00:22:17 each Exp $
|
||||
#
|
||||
# This file must follow /bin/sh rules. It is imported directly via
|
||||
# configure.
|
||||
@@ -6,5 +6,5 @@
|
||||
MAJORVER=9
|
||||
MINORVER=3
|
||||
PATCHVER=5
|
||||
RELEASETYPE=rc
|
||||
RELEASEVER=2
|
||||
RELEASETYPE=
|
||||
RELEASEVER=
|
||||
|
||||
Reference in New Issue
Block a user