ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

This commit was manufactured by cvs2git to create tag 'v9_3_5_P1'.

Browse Source
This commit is contained in:
cvs2git
2008-05-28 19:33:39 +00:00
parent e27a76aad5 6f2f231905
commit 99ba67d065
24 changed files with 1176 additions and 11301 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGES
+5
View File
@@ -1,3 +1,8 @@
--- 9.3.5-P1 released ---
2375. [security] Fully randomize UDP query ports to improve
forgery resilience. [RT #17949]
--- 9.3.5 released ---
--- 9.3.5rc2 released ---
bin/named/client.c
+1 -9
View File
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: client.c,v 1.176.2.13.4.38 2007/08/28 07:19:08 tbox Exp $ */
/* $Id: client.c,v 1.176.2.13.4.38.4.1 2008/05/22 21:11:13 each Exp $ */
#include <config.h>
@@ -1348,14 +1348,6 @@ client_request(isc_task_t *task, isc_event_t *event) {
}
}
/*
* Hash the incoming request here as it is after
* dns_dispatch_importrecv().
*/
dns_dispatch_hash(&client->now, sizeof(client->now));
dns_dispatch_hash(isc_buffer_base(buffer),
isc_buffer_usedlength(buffer));
/*
* It's a request. Parse it.
*/
bin/named/server.c
+27 -7
View File
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: server.c,v 1.339.2.15.2.78 2008/01/17 23:45:27 tbox Exp $ */
/* $Id: server.c,v 1.339.2.15.2.78.4.1 2008/05/22 21:11:14 each Exp $ */
#include <config.h>
@@ -485,6 +485,14 @@ get_view_querysource_dispatch(const cfg_obj_t **maps,
attrs |= DNS_DISPATCHATTR_IPV6;
break;
}
if (isc_sockaddr_getport(&sa) != 0) {
INSIST(obj != NULL);
cfg_obj_log(obj, ns_g_lctx, ISC_LOG_INFO,
"using specific query-source port suppresses port "
"randomization and can be insecure.");
}
attrmask = 0;
attrmask |= DNS_DISPATCHATTR_UDP;
attrmask |= DNS_DISPATCHATTR_TCP;
@@ -494,7 +502,7 @@ get_view_querysource_dispatch(const cfg_obj_t **maps,
disp = NULL;
result = dns_dispatch_getudp(ns_g_dispatchmgr, ns_g_socketmgr,
ns_g_taskmgr, &sa, 4096,
1000, 32768, 16411, 16433,
1024, 32768, 16411, 16433,
attrs, attrmask, &disp);
if (result != ISC_R_SUCCESS) {
isc_sockaddr_t any;
@@ -1866,7 +1874,9 @@ scan_interfaces(ns_server_t *server, isc_boolean_t verbose) {
}
static isc_result_t
add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr) {
add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr,
isc_boolean_t wcardport_ok)
{
ns_listenelt_t *lelt = NULL;
dns_acl_t *src_acl = NULL;
dns_aclelement_t aelt;
@@ -1876,7 +1886,8 @@ add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr) {
REQUIRE(isc_sockaddr_pf(addr) == AF_INET6);
isc_sockaddr_any6(&any_sa6);
if (!isc_sockaddr_equal(&any_sa6, addr)) {
if (!isc_sockaddr_equal(&any_sa6, addr) &&
(wcardport_ok || isc_sockaddr_getport(addr) != 0)) {
aelt.type = dns_aclelementtype_ipprefix;
aelt.negative = ISC_FALSE;
aelt.u.ip_prefix.prefixlen = 128;
@@ -1935,7 +1946,16 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) {
result = dns_dispatch_getlocaladdress(dispatch6, &addr);
if (result != ISC_R_SUCCESS)
goto fail;
result = add_listenelt(mctx, list, &addr);
/*
* We always add non-wildcard address regardless of whether
* the port is 'any' (the fourth arg is TRUE): if the port is
* specific, we need to add it since it may conflict with a
* listening interface; if it's zero, we'll dynamically open
* query ports, and some of them may override an existing
* wildcard IPv6 port.
*/
result = add_listenelt(mctx, list, &addr, ISC_TRUE);
if (result != ISC_R_SUCCESS)
goto fail;
}
@@ -1965,12 +1985,12 @@ adjust_interfaces(ns_server_t *server, isc_mem_t *mctx) {
continue;
addrp = dns_zone_getnotifysrc6(zone);
result = add_listenelt(mctx, list, addrp);
result = add_listenelt(mctx, list, addrp, ISC_FALSE);
if (result != ISC_R_SUCCESS)
goto fail;
addrp = dns_zone_getxfrsource6(zone);
result = add_listenelt(mctx, list, addrp);
result = add_listenelt(mctx, list, addrp, ISC_FALSE);
if (result != ISC_R_SUCCESS)
goto fail;
}
doc/arm/Bv9ARM-book.xml
+10 -2
View File
@@ -18,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.88 2008/01/18 23:45:32 tbox Exp $ -->
<!-- File: $Id: Bv9ARM-book.xml,v 1.155.2.27.2.88.2.1 2008/05/22 21:11:14 each Exp $ -->
<book>
<title>BIND 9 Administrator Reference Manual</title>
@@ -3732,7 +3732,15 @@ IPv6, there is a separate <command>query-source-v6</command> option.
If <command>address</command> is <command>*</command> (asterisk) or is omitted,
a wildcard IP address (<command>INADDR_ANY</command>) will be used.
If <command>port</command> is <command>*</command> or is omitted,
a random unprivileged port will be used. The <command>avoid-v4-udp-ports</command>
a random unprivileged port number is picked up and will be
used for each query.
It is generally strongly discouraged to
specify a particular port for the
<command>query-source</command> or
<command>query-source-v6</command> options;
it implicitly disables the use of randomized port numbers
and leads to insecure operation.
The <command>avoid-v4-udp-ports</command>
and <command>avoid-v6-udp-ports</command> options can be used to prevent named
from selecting certain ports. The defaults are:</para>
<programlisting>query-source address * port *;
doc/arm/Bv9ARM.ch06.html
+10 -2
View File
@@ -14,7 +14,7 @@
- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.12.2.54 2008/01/19 01:52:14 marka Exp $ -->
<!-- $Id: Bv9ARM.ch06.html,v 1.56.2.12.2.54.2.1 2008/05/27 22:09:04 each Exp $ -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -1892,7 +1892,15 @@ IPv6, there is a separate <span><strong class="command">query-source-v6</strong>
If <span><strong class="command">address</strong></span> is <span><strong class="command">*</strong></span> (asterisk) or is omitted,
a wildcard IP address (<span><strong class="command">INADDR_ANY</strong></span>) will be used.
If <span><strong class="command">port</strong></span> is <span><strong class="command">*</strong></span> or is omitted,
a random unprivileged port will be used. The <span><strong class="command">avoid-v4-udp-ports</strong></span>
a random unprivileged port number is picked up and will be
used for each query.
It is generally strongly discouraged to
specify a particular port for the
<span><strong class="command">query-source</strong></span> or
<span><strong class="command">query-source-v6</strong></span> options;
it implicitly disables the use of randomized port numbers
and leads to insecure operation.
The <span><strong class="command">avoid-v4-udp-ports</strong></span>
and <span><strong class="command">avoid-v6-udp-ports</strong></span> options can be used to prevent named
from selecting certain ports. The defaults are:</p>
<pre class="programlisting">query-source address * port *;
doc/arm/Bv9ARM.pdf
+840 -860
View File
File diff suppressed because one or more lines are too long
doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt
-840
View File
@@ -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]
doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
-616
View File
@@ -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]
doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
-504
View File
@@ -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]
doc/draft/draft-ietf-dnsext-mdns-46.txt
-1801
View File
File diff suppressed because it is too large Load Diff
doc/draft/draft-ietf-dnsext-nsid-01.txt
-840
View File
@@ -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]
doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt
-464
View File
@@ -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]
doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt
-580
View File
@@ -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]
doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt
-729
View File
@@ -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]
doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
-1063
View File
File diff suppressed because it is too large Load Diff
doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
-1232
View File
File diff suppressed because it is too large Load Diff
doc/draft/draft-ietf-dnsop-respsize-06.txt
-640
View File
@@ -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]
doc/draft/draft-ietf-dnsop-serverid-06.txt
-618
View File
@@ -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]
lib/dns/api
+3 -3
View File
@@ -1,3 +1,3 @@
LIBINTERFACE = 24
LIBREVISION = 2
LIBAGE = 2
LIBINTERFACE = 25
LIBREVISION = 0
LIBAGE = 0
lib/dns/dispatch.c
+234 -473
View File
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: dispatch.c,v 1.101.2.6.2.21 2007/08/28 07:19:13 tbox Exp $ */
/* $Id: dispatch.c,v 1.101.2.6.2.21.4.1 2008/05/22 21:11:15 each Exp $ */
#include <config.h>
@@ -27,6 +27,7 @@
#include <isc/mem.h>
#include <isc/mutex.h>
#include <isc/print.h>
#include <isc/random.h>
#include <isc/string.h>
#include <isc/task.h>
#include <isc/time.h>
@@ -43,25 +44,22 @@
typedef ISC_LIST(dns_dispentry_t) dns_displist_t;
typedef struct dns_nsid {
isc_uint16_t nsid_state;
isc_uint16_t *nsid_vtable;
isc_uint16_t *nsid_pool;
isc_uint16_t nsid_a1, nsid_a2, nsid_a3;
isc_uint16_t nsid_c1, nsid_c2, nsid_c3;
isc_uint16_t nsid_state2;
isc_boolean_t nsid_usepool;
} dns_nsid_t;
typedef struct dns_qid {
unsigned int magic;
unsigned int qid_nbuckets; /* hash table size */
unsigned int qid_increment; /* id increment on collision */
isc_mutex_t lock;
dns_nsid_t nsid;
dns_displist_t *qid_table; /* the table itself */
} dns_qid_t;
/* ARC4 Random generator state */
typedef struct arc4ctx {
isc_uint8_t i;
isc_uint8_t j;
isc_uint8_t s[256];
int count;
} arc4ctx_t;
struct dns_dispatchmgr {
/* Unlocked. */
unsigned int magic;
@@ -74,6 +72,10 @@ struct dns_dispatchmgr {
unsigned int state;
ISC_LIST(dns_dispatch_t) list;
/* Locked by arc4_lock. */
isc_mutex_t arc4_lock;
arc4ctx_t arc4ctx; /*%< ARC4 context for QID */
/* locked by buffer lock */
dns_qid_t *qid;
isc_mutex_t buffer_lock;
@@ -100,6 +102,7 @@ struct dns_dispentry {
unsigned int magic;
dns_dispatch_t *disp;
dns_messageid_t id;
in_port_t port;
unsigned int bucket;
isc_sockaddr_t host;
isc_task_t *task;
@@ -119,6 +122,7 @@ struct dns_dispatch {
isc_task_t *task; /* internal task */
isc_socket_t *socket; /* isc socket attached to */
isc_sockaddr_t local; /* local address */
in_port_t localport; /* local UDP port */
unsigned int maxrequests; /* max requests */
isc_event_t *ctlevent;
@@ -161,14 +165,14 @@ struct dns_dispatch {
* Statics.
*/
static dns_dispentry_t *bucket_search(dns_qid_t *, isc_sockaddr_t *,
dns_messageid_t, unsigned int);
dns_messageid_t, in_port_t, unsigned int);
static isc_boolean_t destroy_disp_ok(dns_dispatch_t *);
static void destroy_disp(isc_task_t *task, isc_event_t *event);
static void udp_recv(isc_task_t *, isc_event_t *);
static void tcp_recv(isc_task_t *, isc_event_t *);
static void startrecv(dns_dispatch_t *);
static dns_messageid_t dns_randomid(dns_nsid_t *);
static isc_uint32_t dns_hash(dns_qid_t *, isc_sockaddr_t *, dns_messageid_t);
static isc_uint32_t dns_hash(dns_qid_t *, isc_sockaddr_t *, dns_messageid_t,
in_port_t);
static void free_buffer(dns_dispatch_t *disp, void *buf, unsigned int len);
static void *allocate_udp_buffer(dns_dispatch_t *disp);
static inline void free_event(dns_dispatch_t *disp, dns_dispatchevent_t *ev);
@@ -188,12 +192,8 @@ static isc_result_t dispatch_createudp(dns_dispatchmgr_t *mgr,
static isc_boolean_t destroy_mgr_ok(dns_dispatchmgr_t *mgr);
static void destroy_mgr(dns_dispatchmgr_t **mgrp);
static isc_result_t qid_allocate(dns_dispatchmgr_t *mgr, unsigned int buckets,
unsigned int increment, isc_boolean_t usepool,
dns_qid_t **qidp);
unsigned int increment, dns_qid_t **qidp);
static void qid_destroy(isc_mem_t *mctx, dns_qid_t **qidp);
static isc_uint16_t nsid_next(dns_nsid_t *nsid);
static isc_result_t nsid_init(isc_mem_t *mctx, dns_nsid_t *nsid, isc_boolean_t usepool);
static void nsid_destroy(isc_mem_t *mctx, dns_nsid_t *nsid);
#define LVL(x) ISC_LOG_DEBUG(x)
@@ -274,26 +274,152 @@ request_log(dns_dispatch_t *disp, dns_dispentry_t *resp,
}
/*
* Return an unpredictable message ID.
* ARC4 random number generator obtained from OpenBSD
*/
static dns_messageid_t
dns_randomid(dns_nsid_t *nsid) {
isc_uint32_t id;
static void
dispatch_arc4init(arc4ctx_t *actx) {
int n;
for (n = 0; n < 256; n++)
actx->s[n] = n;
actx->i = 0;
actx->j = 0;
actx->count = 0;
}
id = nsid_next(nsid);
static void
dispatch_arc4addrandom(arc4ctx_t *actx, unsigned char *dat, int datlen) {
int n;
isc_uint8_t si;
return ((dns_messageid_t)id);
actx->i--;
for (n = 0; n < 256; n++) {
actx->i = (actx->i + 1);
si = actx->s[actx->i];
actx->j = (actx->j + si + dat[n % datlen]);
actx->s[actx->i] = actx->s[actx->j];
actx->s[actx->j] = si;
}
actx->j = actx->i;
}
static inline isc_uint8_t
dispatch_arc4get8(arc4ctx_t *actx) {
isc_uint8_t si, sj;
actx->i = (actx->i + 1);
si = actx->s[actx->i];
actx->j = (actx->j + si);
sj = actx->s[actx->j];
actx->s[actx->i] = sj;
actx->s[actx->j] = si;
return (actx->s[(si + sj) & 0xff]);
}
static inline isc_uint16_t
dispatch_arc4get16(arc4ctx_t *actx) {
isc_uint16_t val;
val = dispatch_arc4get8(actx) << 8;
val |= dispatch_arc4get8(actx);
return (val);
}
static void
dispatch_arc4stir(dns_dispatchmgr_t *mgr) {
int i;
union {
unsigned char rnd[128];
isc_uint32_t rnd32[32];
} rnd;
isc_result_t result;
if (mgr->entropy != NULL) {
/*
* We accept any quality of random data to avoid blocking.
*/
result = isc_entropy_getdata(mgr->entropy, rnd.rnd,
sizeof(rnd), NULL, 0);
RUNTIME_CHECK(result == ISC_R_SUCCESS);
} else {
for (i = 0; i < 32; i++)
isc_random_get(&rnd.rnd32[i]);
}
dispatch_arc4addrandom(&mgr->arc4ctx, rnd.rnd, sizeof(rnd.rnd));
/*
* Discard early keystream, as per recommendations in:
* http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
*/
for (i = 0; i < 256; i++)
(void)dispatch_arc4get8(&mgr->arc4ctx);
/*
* Derived from OpenBSD's implementation. The rationale is not clear,
* but should be conservative enough in safety, and reasonably large
* for efficiency.
*/
mgr->arc4ctx.count = 1600000;
}
static isc_uint16_t
dispatch_arc4random(dns_dispatchmgr_t *mgr) {
isc_uint16_t result;
LOCK(&mgr->arc4_lock);
mgr->arc4ctx.count -= sizeof(isc_uint16_t);
if (mgr->arc4ctx.count <= 0)
dispatch_arc4stir(mgr);
result = dispatch_arc4get16(&mgr->arc4ctx);
UNLOCK(&mgr->arc4_lock);
return (result);
}
static isc_uint16_t
dispatch_arc4uniformrandom(dns_dispatchmgr_t *mgr, isc_uint16_t upper_bound) {
isc_uint16_t min, r;
/* The caller must hold the manager lock. */
if (upper_bound < 2)
return (0);
/*
* Ensure the range of random numbers [min, 0xffff] be a multiple of
* upper_bound and contain at least a half of the 16 bit range.
*/
if (upper_bound > 0x8000)
min = 1 + ~upper_bound; /* 0x8000 - upper_bound */
else
min = (isc_uint16_t)(0x10000 % (isc_uint32_t)upper_bound);
/*
* This could theoretically loop forever but each retry has
* p > 0.5 (worst case, usually far better) of selecting a
* number inside the range we need, so it should rarely need
* to re-roll.
*/
for (;;) {
r = dispatch_arc4random(mgr);
if (r >= min)
break;
}
return (r % upper_bound);
}
/*
* Return a hash of the destination and message id.
*/
static isc_uint32_t
dns_hash(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id) {
dns_hash(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id,
in_port_t port)
{
unsigned int ret;
ret = isc_sockaddr_hash(dest, ISC_TRUE);
ret ^= id;
ret ^= (id << 16) | port;
ret %= qid->qid_nbuckets;
INSIST(ret < qid->qid_nbuckets);
@@ -410,7 +536,7 @@ destroy_disp(isc_task_t *task, isc_event_t *event) {
*/
static dns_dispentry_t *
bucket_search(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id,
unsigned int bucket)
in_port_t port, unsigned int bucket)
{
dns_dispentry_t *res;
@@ -419,8 +545,10 @@ bucket_search(dns_qid_t *qid, isc_sockaddr_t *dest, dns_messageid_t id,
res = ISC_LIST_HEAD(qid->qid_table[bucket]);
while (res != NULL) {
if ((res->id == id) && isc_sockaddr_equal(dest, &res->host))
if ((res->id == id) && isc_sockaddr_equal(dest, &res->host) &&
res->port == port) {
return (res);
}
res = ISC_LIST_NEXT(res, link);
}
@@ -622,13 +750,10 @@ udp_recv(isc_task_t *task, isc_event_t *ev_in) {
goto restart;
}
dns_dispatch_hash(&ev->timestamp, sizeof(&ev->timestamp));
dns_dispatch_hash(ev->region.base, ev->region.length);
/* response */
bucket = dns_hash(qid, &ev->address, id);
bucket = dns_hash(qid, &ev->address, id, disp->localport);
LOCK(&qid->lock);
resp = bucket_search(qid, &ev->address, id, bucket);
resp = bucket_search(qid, &ev->address, id, disp->localport, bucket);
dispatch_log(disp, LVL(90),
"search for response in bucket %d: %s",
bucket, (resp == NULL ? "not found" : "found"));
@@ -859,14 +984,13 @@ tcp_recv(isc_task_t *task, isc_event_t *ev_in) {
goto restart;
}
dns_dispatch_hash(tcpmsg->buffer.base, tcpmsg->buffer.length);
/*
* Response.
*/
bucket = dns_hash(qid, &tcpmsg->address, id);
bucket = dns_hash(qid, &tcpmsg->address, id, disp->localport);
LOCK(&qid->lock);
resp = bucket_search(qid, &tcpmsg->address, id, bucket);
resp = bucket_search(qid, &tcpmsg->address, id, disp->localport,
bucket);
dispatch_log(disp, LVL(90),
"search for response in bucket %d: %s",
bucket, (resp == NULL ? "not found" : "found"));
@@ -1015,6 +1139,8 @@ destroy_mgr(dns_dispatchmgr_t **mgrp) {
DESTROYLOCK(&mgr->lock);
mgr->state = 0;
DESTROYLOCK(&mgr->arc4_lock);
isc_mempool_destroy(&mgr->epool);
isc_mempool_destroy(&mgr->rpool);
isc_mempool_destroy(&mgr->dpool);
@@ -1093,10 +1219,14 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
if (result != ISC_R_SUCCESS)
goto deallocate;
result = isc_mutex_init(&mgr->buffer_lock);
result = isc_mutex_init(&mgr->arc4_lock);
if (result != ISC_R_SUCCESS)
goto kill_lock;
result = isc_mutex_init(&mgr->buffer_lock);
if (result != ISC_R_SUCCESS)
goto kill_arc4_lock;
result = isc_mutex_init(&mgr->pool_lock);
if (result != ISC_R_SUCCESS)
goto kill_buffer_lock;
@@ -1147,6 +1277,8 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
if (entropy != NULL)
isc_entropy_attach(entropy, &mgr->entropy);
dispatch_arc4init(&mgr->arc4ctx);
*mgrp = mgr;
return (ISC_R_SUCCESS);
@@ -1158,6 +1290,8 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
DESTROYLOCK(&mgr->pool_lock);
kill_buffer_lock:
DESTROYLOCK(&mgr->buffer_lock);
kill_arc4_lock:
DESTROYLOCK(&mgr->arc4_lock);
kill_lock:
DESTROYLOCK(&mgr->lock);
deallocate:
@@ -1245,7 +1379,7 @@ dns_dispatchmgr_setudp(dns_dispatchmgr_t *mgr,
isc_mempool_setmaxalloc(mgr->bpool, maxbuffers);
isc_mempool_associatelock(mgr->bpool, &mgr->pool_lock);
result = qid_allocate(mgr, buckets, increment, ISC_TRUE, &mgr->qid);
result = qid_allocate(mgr, buckets, increment, &mgr->qid);
if (result != ISC_R_SUCCESS)
goto cleanup;
@@ -1284,20 +1418,27 @@ dns_dispatchmgr_destroy(dns_dispatchmgr_t **mgrp) {
}
static isc_boolean_t
blacklisted(dns_dispatchmgr_t *mgr, isc_socket_t *sock) {
blacklisted(dns_dispatchmgr_t *mgr, isc_socket_t *sock,
isc_sockaddr_t *sockaddrp)
{
isc_sockaddr_t sockaddr;
isc_result_t result;
REQUIRE(sock != NULL || sockaddrp != NULL);
if (mgr->portlist == NULL)
return (ISC_FALSE);
result = isc_socket_getsockname(sock, &sockaddr);
if (result != ISC_R_SUCCESS)
return (ISC_FALSE);
if (sock != NULL) {
sockaddrp = &sockaddr;
result = isc_socket_getsockname(sock, sockaddrp);
if (result != ISC_R_SUCCESS)
return (ISC_FALSE);
}
if (mgr->portlist != NULL &&
dns_portlist_match(mgr->portlist, isc_sockaddr_pf(&sockaddr),
isc_sockaddr_getport(&sockaddr)))
dns_portlist_match(mgr->portlist, isc_sockaddr_pf(sockaddrp),
isc_sockaddr_getport(sockaddrp)))
return (ISC_TRUE);
return (ISC_FALSE);
}
@@ -1318,7 +1459,7 @@ local_addr_match(dns_dispatch_t *disp, isc_sockaddr_t *addr) {
if (disp->mgr->portlist != NULL &&
isc_sockaddr_getport(addr) == 0 &&
isc_sockaddr_getport(&disp->local) == 0 &&
blacklisted(disp->mgr, disp->socket))
blacklisted(disp->mgr, disp->socket, NULL))
return (ISC_FALSE);
/*
@@ -1391,7 +1532,7 @@ dispatch_find(dns_dispatchmgr_t *mgr, isc_sockaddr_t *local,
static isc_result_t
qid_allocate(dns_dispatchmgr_t *mgr, unsigned int buckets,
unsigned int increment, isc_boolean_t usepool, dns_qid_t **qidp)
unsigned int increment, dns_qid_t **qidp)
{
dns_qid_t *qid;
unsigned int i;
@@ -1412,16 +1553,8 @@ qid_allocate(dns_dispatchmgr_t *mgr, unsigned int buckets,
return (ISC_R_NOMEMORY);
}
if (nsid_init(mgr->mctx, &qid->nsid, usepool) != ISC_R_SUCCESS) {
isc_mem_put(mgr->mctx, qid->qid_table,
buckets * sizeof(dns_displist_t));
isc_mem_put(mgr->mctx, qid, sizeof(*qid));
return (ISC_R_NOMEMORY);
}
if (isc_mutex_init(&qid->lock) != ISC_R_SUCCESS) {
UNEXPECTED_ERROR(__FILE__, __LINE__, "isc_mutex_init failed");
nsid_destroy(mgr->mctx, &qid->nsid);
isc_mem_put(mgr->mctx, qid->qid_table,
buckets * sizeof(dns_displist_t));
isc_mem_put(mgr->mctx, qid, sizeof(*qid));
@@ -1449,7 +1582,6 @@ qid_destroy(isc_mem_t *mctx, dns_qid_t **qidp) {
*qidp = NULL;
qid->magic = 0;
nsid_destroy(mctx, &qid->nsid);
isc_mem_put(mctx, qid->qid_table,
qid->qid_nbuckets * sizeof(dns_displist_t));
DESTROYLOCK(&qid->lock);
@@ -1486,6 +1618,7 @@ dispatch_allocate(dns_dispatchmgr_t *mgr, unsigned int maxrequests,
disp->refcount = 1;
disp->recv_pending = 0;
memset(&disp->local, 0, sizeof(disp->local));
disp->localport = 0;
disp->shutting_down = 0;
disp->shutdown_out = 0;
disp->connected = 0;
@@ -1593,7 +1726,7 @@ dns_dispatch_createtcp(dns_dispatchmgr_t *mgr, isc_socket_t *sock,
return (result);
}
result = qid_allocate(mgr, buckets, increment, ISC_FALSE, &disp->qid);
result = qid_allocate(mgr, buckets, increment, &disp->qid);
if (result != ISC_R_SUCCESS)
goto deallocate_dispatch;
@@ -1660,7 +1793,7 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
dns_dispatch_t **dispp)
{
isc_result_t result;
dns_dispatch_t *disp;
dns_dispatch_t *disp = NULL;
REQUIRE(VALID_DISPATCHMGR(mgr));
REQUIRE(sockmgr != NULL);
@@ -1680,6 +1813,11 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
LOCK(&mgr->lock);
if ((attributes & DNS_DISPATCHATTR_RANDOMPORT) != 0) {
REQUIRE(isc_sockaddr_getport(localaddr) == 0);
goto createudp;
}
/*
* First, see if we have a dispatcher that matches.
*/
@@ -1708,6 +1846,7 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
return (ISC_R_SUCCESS);
}
createudp:
/*
* Nope, create one.
*/
@@ -1743,7 +1882,9 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
dns_dispatch_t *disp;
isc_socket_t *sock = NULL;
isc_socket_t *held[DNS_DISPATCH_HELD];
unsigned int i = 0, j = 0;
unsigned int i = 0, j = 0, k = 0;
isc_sockaddr_t localaddr_bound;
in_port_t localport = 0;
/*
* dispatch_allocate() checks mgr for us.
@@ -1759,11 +1900,34 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
* from returning the same port to us too quickly.
*/
memset(held, 0, sizeof(held));
localaddr_bound = *localaddr;
getsocket:
result = create_socket(sockmgr, localaddr, &sock);
if ((attributes & DNS_DISPATCHATTR_RANDOMPORT) != 0) {
in_port_t prt;
/* XXX: should the range be configurable? */
prt = 1024 + dispatch_arc4uniformrandom(mgr, 65535 - 1023);
isc_sockaddr_setport(&localaddr_bound, prt);
if (blacklisted(mgr, NULL, &localaddr_bound)) {
if (++k == 1024)
attributes &= ~DNS_DISPATCHATTR_RANDOMPORT;
goto getsocket;
}
result = create_socket(sockmgr, &localaddr_bound, &sock);
if (result == ISC_R_ADDRINUSE) {
if (++k == 1024)
attributes &= ~DNS_DISPATCHATTR_RANDOMPORT;
goto getsocket;
}
localport = prt;
} else
result = create_socket(sockmgr, localaddr, &sock);
if (result != ISC_R_SUCCESS)
goto deallocate_dispatch;
if (isc_sockaddr_getport(localaddr) == 0 && blacklisted(mgr, sock)) {
if ((attributes & DNS_DISPATCHATTR_RANDOMPORT) == 0 &&
isc_sockaddr_getport(localaddr) == 0 &&
blacklisted(mgr, sock, NULL))
{
if (held[i] != NULL)
isc_socket_detach(&held[i]);
held[i++] = sock;
@@ -1784,6 +1948,7 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
disp->socktype = isc_sockettype_udp;
disp->socket = sock;
disp->local = *localaddr;
disp->localport = localport;
disp->task = NULL;
result = isc_task_create(taskmgr, 0, &disp->task);
@@ -1916,19 +2081,20 @@ dns_dispatch_addresponse(dns_dispatch_t *disp, isc_sockaddr_t *dest,
/*
* Try somewhat hard to find an unique ID.
*/
id = (dns_messageid_t)dispatch_arc4random(disp->mgr);
qid = DNS_QID(disp);
LOCK(&qid->lock);
id = dns_randomid(&qid->nsid);
bucket = dns_hash(qid, dest, id);
bucket = dns_hash(qid, dest, id, disp->localport);
ok = ISC_FALSE;
for (i = 0; i < 64; i++) {
if (bucket_search(qid, dest, id, bucket) == NULL) {
if (bucket_search(qid, dest, id, disp->localport, bucket) ==
NULL) {
ok = ISC_TRUE;
break;
}
id += qid->qid_increment;
id &= 0x0000ffff;
bucket = dns_hash(qid, dest, id);
bucket = dns_hash(qid, dest, id, disp->localport);
}
if (!ok) {
@@ -1950,6 +2116,7 @@ dns_dispatch_addresponse(dns_dispatch_t *disp, isc_sockaddr_t *dest,
isc_task_attach(task, &res->task);
res->disp = disp;
res->id = id;
res->port = disp->localport;
res->bucket = bucket;
res->host = *dest;
res->action = action;
@@ -2261,409 +2428,3 @@ dns_dispatchmgr_dump(dns_dispatchmgr_t *mgr) {
}
}
#endif
/*
* Allow the user to pick one of two ID randomization algorithms.
*
* The first algorithm is an adaptation of the sequence shuffling
* algorithm discovered by Carter Bays and S. D. Durham [ACM Trans. Math.
* Software 2 (1976), 59-64], as documented as Algorithm B in Chapter
* 3.2.2 in Volume 2 of Knuth's "The Art of Computer Programming". We use
* a randomly selected linear congruential random number generator with a
* modulus of 2^16, whose increment is a randomly picked odd number, and
* whose multiplier is picked from a set which meets the following
* criteria:
* Is of the form 8*n+5, which ensures "high potency" according to
* principle iii in the summary chapter 3.6. This form also has a
* gcd(a-1,m) of 4 which is good according to principle iv.
*
* Is between 0.01 and 0.99 times the modulus as specified by
* principle iv.
*
* Passes the spectral test "with flying colors" (ut >= 1) in
* dimensions 2 through 6 as calculated by Algorithm S in Chapter
* 3.3.4 and the ratings calculated by formula 35 in section E.
*
* Of the multipliers that pass this test, pick the set that is
* best according to the theoretical bounds of the serial
* correlation test. This was calculated using a simplified
* version of Knuth's Theorem K in Chapter 3.3.3.
*
* These criteria may not be important for this use, but we might as well
* pick from the best generators since there are so many possible ones and
* we don't have that many random bits to do the picking.
*
* We use a modulus of 2^16 instead of something bigger so that we will
* tend to cycle through all the possible IDs before repeating any,
* however the shuffling will perturb this somewhat. Theoretically there
* is no minimimum interval between two uses of the same ID, but in
* practice it seems to be >64000.
*
* Our adaptatation of Algorithm B mixes the hash state which has
* captured various random events into the shuffler to perturb the
* sequence.
*
* One disadvantage of this algorithm is that if the generator parameters
* were to be guessed, it would be possible to mount a limited brute force
* attack on the ID space since the IDs are only shuffled within a limited
* range.
*
* The second algorithm uses the same random number generator to populate
* a pool of 65536 IDs. The hash state is used to pick an ID from a window
* of 4096 IDs in this pool, then the chosen ID is swapped with the ID
* at the beginning of the window and the window position is advanced.
* This means that the interval between uses of the ID will be no less
* than 65536-4096. The ID sequence in the pool will become more random
* over time.
*
* For both algorithms, two more linear congruential random number generators
* are selected. The ID from the first part of algorithm is used to seed
* the first of these generators, and its output is used to seed the second.
* The strategy is use these generators as 1 to 1 hashes to obfuscate the
* properties of the generator used in the first part of either algorithm.
*
* The first algorithm may be suitable for use in a client resolver since
* its memory requirements are fairly low and it's pretty random out of
* the box. It is somewhat succeptible to a limited brute force attack,
* so the second algorithm is probably preferable for a longer running
* program that issues a large number of queries and has time to randomize
* the pool.
*/
#define NSID_SHUFFLE_TABLE_SIZE 100 /* Suggested by Knuth */
/*
* Pick one of the next 4096 IDs in the pool.
* There is a tradeoff here between randomness and how often and ID is reused.
*/
#define NSID_LOOKAHEAD 4096 /* Must be a power of 2 */
#define NSID_SHUFFLE_ONLY 1 /* algorithm 1 */
#define NSID_USE_POOL 2 /* algorithm 2 */
#define NSID_HASHSHIFT 3
#define NSID_HASHROTATE(v) \
(((v) << NSID_HASHSHIFT) | ((v) >> ((sizeof(v) * 8) - NSID_HASHSHIFT)))
static isc_uint32_t nsid_hash_state;
/*
* Keep a running hash of various bits of data that we'll use to
* stir the ID pool or perturb the ID generator
*/
static void
nsid_hash(void *data, size_t len) {
unsigned char *p = data;
/*
* Hash function similar to the one we use for hashing names.
* We don't fold case or toss the upper bit here, though.
* This hash doesn't do much interesting when fed binary zeros,
* so there may be a better hash function.
* This function doesn't need to be very strong since we're
* only using it to stir the pool, but it should be reasonably
* fast.
*/
/*
* We don't care about locking access to nsid_hash_state.
* In fact races make the result even more non deteministic.
*/
while (len-- > 0U) {
nsid_hash_state = NSID_HASHROTATE(nsid_hash_state);
nsid_hash_state += *p++;
}
}
/*
* Table of good linear congruential multipliers for modulus 2^16
* in order of increasing serial correlation bounds (so trim from
* the end).
*/
static const isc_uint16_t nsid_multiplier_table[] = {
17565, 25013, 11733, 19877, 23989, 23997, 24997, 25421,
26781, 27413, 35901, 35917, 35973, 36229, 38317, 38437,
39941, 40493, 41853, 46317, 50581, 51429, 53453, 53805,
11317, 11789, 12045, 12413, 14277, 14821, 14917, 18989,
19821, 23005, 23533, 23573, 23693, 27549, 27709, 28461,
29365, 35605, 37693, 37757, 38309, 41285, 45261, 47061,
47269, 48133, 48597, 50277, 50717, 50757, 50805, 51341,
51413, 51581, 51597, 53445, 11493, 14229, 20365, 20653,
23485, 25541, 27429, 29421, 30173, 35445, 35653, 36789,
36797, 37109, 37157, 37669, 38661, 39773, 40397, 41837,
41877, 45293, 47277, 47845, 49853, 51085, 51349, 54085,
56933, 8877, 8973, 9885, 11365, 11813, 13581, 13589,
13613, 14109, 14317, 15765, 15789, 16925, 17069, 17205,
17621, 17941, 19077, 19381, 20245, 22845, 23733, 24869,
25453, 27213, 28381, 28965, 29245, 29997, 30733, 30901,
34877, 35485, 35613, 36133, 36661, 36917, 38597, 40285,
40693, 41413, 41541, 41637, 42053, 42349, 45245, 45469,
46493, 48205, 48613, 50861, 51861, 52877, 53933, 54397,
55669, 56453, 56965, 58021, 7757, 7781, 8333, 9661,
12229, 14373, 14453, 17549, 18141, 19085, 20773, 23701,
24205, 24333, 25261, 25317, 27181, 30117, 30477, 34757,
34885, 35565, 35885, 36541, 37957, 39733, 39813, 41157,
41893, 42317, 46621, 48117, 48181, 49525, 55261, 55389,
56845, 7045, 7749, 7965, 8469, 9133, 9549, 9789,
10173, 11181, 11285, 12253, 13453, 13533, 13757, 14477,
15053, 16901, 17213, 17269, 17525, 17629, 18605, 19013,
19829, 19933, 20069, 20093, 23261, 23333, 24949, 25309,
27613, 28453, 28709, 29301, 29541, 34165, 34413, 37301,
37773, 38045, 38405, 41077, 41781, 41925, 42717, 44437,
44525, 44613, 45933, 45941, 47077, 50077, 50893, 52117,
5293, 55069, 55989, 58125, 59205, 6869, 14685, 15453,
16821, 17045, 17613, 18437, 21029, 22773, 22909, 25445,
25757, 26541, 30709, 30909, 31093, 31149, 37069, 37725,
37925, 38949, 39637, 39701, 40765, 40861, 42965, 44813,
45077, 45733, 47045, 50093, 52861, 52957, 54181, 56325,
56365, 56381, 56877, 57013, 5741, 58101, 58669, 8613,
10045, 10261, 10653, 10733, 11461, 12261, 14069, 15877,
17757, 21165, 23885, 24701, 26429, 26645, 27925, 28765,
29197, 30189, 31293, 39781, 39909, 40365, 41229, 41453,
41653, 42165, 42365, 47421, 48029, 48085, 52773, 5573,
57037, 57637, 58341, 58357, 58901, 6357, 7789, 9093,
10125, 10709, 10765, 11957, 12469, 13437, 13509, 14773,
15437, 15773, 17813, 18829, 19565, 20237, 23461, 23685,
23725, 23941, 24877, 25461, 26405, 29509, 30285, 35181,
37229, 37893, 38565, 40293, 44189, 44581, 45701, 47381,
47589, 48557, 4941, 51069, 5165, 52797, 53149, 5341,
56301, 56765, 58581, 59493, 59677, 6085, 6349, 8293,
8501, 8517, 11597, 11709, 12589, 12693, 13517, 14909,
17397, 18085, 21101, 21269, 22717, 25237, 25661, 29189,
30101, 31397, 33933, 34213, 34661, 35533, 36493, 37309,
40037, 4189, 42909, 44309, 44357, 44389, 4541, 45461,
46445, 48237, 54149, 55301, 55853, 56621, 56717, 56901,
5813, 58437, 12493, 15365, 15989, 17829, 18229, 19341,
21013, 21357, 22925, 24885, 26053, 27581, 28221, 28485,
30605, 30613, 30789, 35437, 36285, 37189, 3941, 41797,
4269, 42901, 43293, 44645, 45221, 46893, 4893, 50301,
50325, 5189, 52109, 53517, 54053, 54485, 5525, 55949,
56973, 59069, 59421, 60733, 61253, 6421, 6701, 6709,
7101, 8669, 15797, 19221, 19837, 20133, 20957, 21293,
21461, 22461, 29085, 29861, 30869, 34973, 36469, 37565,
38125, 38829, 39469, 40061, 40117, 44093, 47429, 48341,
50597, 51757, 5541, 57629, 58405, 59621, 59693, 59701,
61837, 7061, 10421, 11949, 15405, 20861, 25397, 25509,
25893, 26037, 28629, 28869, 29605, 30213, 34205, 35637,
36365, 37285, 3773, 39117, 4021, 41061, 42653, 44509,
4461, 44829, 4725, 5125, 52269, 56469, 59085, 5917,
60973, 8349, 17725, 18637, 19773, 20293, 21453, 22533,
24285, 26333, 26997, 31501, 34541, 34805, 37509, 38477,
41333, 44125, 46285, 46997, 47637, 48173, 4925, 50253,
50381, 50917, 51205, 51325, 52165, 52229, 5253, 5269,
53509, 56253, 56341, 5821, 58373, 60301, 61653, 61973,
62373, 8397, 11981, 14341, 14509, 15077, 22261, 22429,
24261, 28165, 28685, 30661, 34021, 34445, 39149, 3917,
43013, 43317, 44053, 44101, 4533, 49541, 49981, 5277,
54477, 56357, 57261, 57765, 58573, 59061, 60197, 61197,
62189, 7725, 8477, 9565, 10229, 11437, 14613, 14709,
16813, 20029, 20677, 31445, 3165, 31957, 3229, 33541,
36645, 3805, 38973, 3965, 4029, 44293, 44557, 46245,
48917, 4909, 51749, 53709, 55733, 56445, 5925, 6093,
61053, 62637, 8661, 9109, 10821, 11389, 13813, 14325,
15501, 16149, 18845, 22669, 26437, 29869, 31837, 33709,
33973, 34173, 3677, 3877, 3981, 39885, 42117, 4421,
44221, 44245, 44693, 46157, 47309, 5005, 51461, 52037,
55333, 55693, 56277, 58949, 6205, 62141, 62469, 6293,
10101, 12509, 14029, 17997, 20469, 21149, 25221, 27109,
2773, 2877, 29405, 31493, 31645, 4077, 42005, 42077,
42469, 42501, 44013, 48653, 49349, 4997, 50101, 55405,
56957, 58037, 59429, 60749, 61797, 62381, 62837, 6605,
10541, 23981, 24533, 2701, 27333, 27341, 31197, 33805,
3621, 37381, 3749, 3829, 38533, 42613, 44381, 45901,
48517, 51269, 57725, 59461, 60045, 62029, 13805, 14013,
15461, 16069, 16157, 18573, 2309, 23501, 28645, 3077,
31541, 36357, 36877, 3789, 39429, 39805, 47685, 47949,
49413, 5485, 56757, 57549, 57805, 58317, 59549, 62213,
62613, 62853, 62933, 8909, 12941, 16677, 20333, 21541,
24429, 26077, 26421, 2885, 31269, 33381, 3661, 40925,
42925, 45173, 4525, 4709, 53133, 55941, 57413, 57797,
62125, 62237, 62733, 6773, 12317, 13197, 16533, 16933,
18245, 2213, 2477, 29757, 33293, 35517, 40133, 40749,
4661, 49941, 62757, 7853, 8149, 8573, 11029, 13421,
21549, 22709, 22725, 24629, 2469, 26125, 2669, 34253,
36709, 41013, 45597, 46637, 52285, 52333, 54685, 59013,
60997, 61189, 61981, 62605, 62821, 7077, 7525, 8781,
10861, 15277, 2205, 22077, 28517, 28949, 32109, 33493,
4661, 49941, 62757, 7853, 8149, 8573, 11029, 13421,
21549, 22709, 22725, 24629, 2469, 26125, 2669, 34253,
36709, 41013, 45597, 46637, 52285, 52333, 54685, 59013,
60997, 61189, 61981, 62605, 62821, 7077, 7525, 8781,
10861, 15277, 2205, 22077, 28517, 28949, 32109, 33493,
3685, 39197, 39869, 42621, 44997, 48565, 5221, 57381,
61749, 62317, 63245, 63381, 23149, 2549, 28661, 31653,
33885, 36341, 37053, 39517, 42805, 45853, 48997, 59349,
60053, 62509, 63069, 6525, 1893, 20181, 2365, 24893,
27397, 31357, 32277, 33357, 34437, 36677, 37661, 43469,
43917, 50997, 53869, 5653, 13221, 16741, 17893, 2157,
28653, 31789, 35301, 35821, 61613, 62245, 12405, 14517,
17453, 18421, 3149, 3205, 40341, 4109, 43941, 46869,
48837, 50621, 57405, 60509, 62877, 8157, 12933, 12957,
16501, 19533, 3461, 36829, 52357, 58189, 58293, 63053,
17109, 1933, 32157, 37701, 59005, 61621, 13029, 15085,
16493, 32317, 35093, 5061, 51557, 62221, 20765, 24613,
2629, 30861, 33197, 33749, 35365, 37933, 40317, 48045,
56229, 61157, 63797, 7917, 17965, 1917, 1973, 20301,
2253, 33157, 58629, 59861, 61085, 63909, 8141, 9221,
14757, 1581, 21637, 26557, 33869, 34285, 35733, 40933,
42517, 43501, 53653, 61885, 63805, 7141, 21653, 54973,
31189, 60061, 60341, 63357, 16045, 2053, 26069, 33997,
43901, 54565, 63837, 8949, 17909, 18693, 32349, 33125,
37293, 48821, 49053, 51309, 64037, 7117, 1445, 20405,
23085, 26269, 26293, 27349, 32381, 33141, 34525, 36461,
37581, 43525, 4357, 43877, 5069, 55197, 63965, 9845,
12093, 2197, 2229, 32165, 33469, 40981, 42397, 8749,
10853, 1453, 18069, 21693, 30573, 36261, 37421, 42533
};
#define NSID_MULT_TABLE_SIZE \
((sizeof nsid_multiplier_table)/(sizeof nsid_multiplier_table[0]))
#define NSID_RANGE_MASK (NSID_LOOKAHEAD - 1)
#define NSID_POOL_MASK 0xFFFF /* used to wrap the pool index */
#define NSID_SHUFFLE_ONLY 1
#define NSID_USE_POOL 2
static isc_uint16_t
nsid_next(dns_nsid_t *nsid) {
isc_uint16_t id, compressed_hash;
isc_uint16_t j;
compressed_hash = ((nsid_hash_state >> 16) ^
(nsid_hash_state)) & 0xFFFF;
if (nsid->nsid_usepool) {
isc_uint16_t pick;
pick = compressed_hash & NSID_RANGE_MASK;
pick = (nsid->nsid_state + pick) & NSID_POOL_MASK;
id = nsid->nsid_pool[pick];
if (pick != 0) {
/* Swap two IDs to stir the pool */
nsid->nsid_pool[pick] =
nsid->nsid_pool[nsid->nsid_state];
nsid->nsid_pool[nsid->nsid_state] = id;
}
/* increment the base pointer into the pool */
if (nsid->nsid_state == 65535)
nsid->nsid_state = 0;
else
nsid->nsid_state++;
} else {
/*
* This is the original Algorithm B
* j = ((u_long) NSID_SHUFFLE_TABLE_SIZE * nsid_state2) >> 16;
*
* We'll perturb it with some random stuff ...
*/
j = ((isc_uint32_t) NSID_SHUFFLE_TABLE_SIZE *
(nsid->nsid_state2 ^ compressed_hash)) >> 16;
nsid->nsid_state2 = id = nsid->nsid_vtable[j];
nsid->nsid_state = (((isc_uint32_t) nsid->nsid_a1 * nsid->nsid_state) +
nsid->nsid_c1) & 0xFFFF;
nsid->nsid_vtable[j] = nsid->nsid_state;
}
/* Now lets obfuscate ... */
id = (((isc_uint32_t) nsid->nsid_a2 * id) + nsid->nsid_c2) & 0xFFFF;
id = (((isc_uint32_t) nsid->nsid_a3 * id) + nsid->nsid_c3) & 0xFFFF;
return (id);
}
static isc_result_t
nsid_init(isc_mem_t *mctx, dns_nsid_t *nsid, isc_boolean_t usepool) {
isc_time_t now;
pid_t mypid;
isc_uint16_t a1ndx, a2ndx, a3ndx, c1ndx, c2ndx, c3ndx;
int i;
isc_time_now(&now);
mypid = getpid();
/* Initialize the state */
memset(nsid, 0, sizeof(*nsid));
nsid_hash(&now, sizeof now);
nsid_hash(&mypid, sizeof mypid);
/*
* Select our random number generators and initial seed.
* We could really use more random bits at this point,
* but we'll try to make a silk purse out of a sows ear ...
*/
/* generator 1 */
a1ndx = ((isc_uint32_t) NSID_MULT_TABLE_SIZE *
(nsid_hash_state & 0xFFFF)) >> 16;
nsid->nsid_a1 = nsid_multiplier_table[a1ndx];
c1ndx = (nsid_hash_state >> 9) & 0x7FFF;
nsid->nsid_c1 = 2 * c1ndx + 1;
/* generator 2, distinct from 1 */
a2ndx = ((isc_uint32_t) (NSID_MULT_TABLE_SIZE - 1) *
((nsid_hash_state >> 10) & 0xFFFF)) >> 16;
if (a2ndx >= a1ndx)
a2ndx++;
nsid->nsid_a2 = nsid_multiplier_table[a2ndx];
c2ndx = nsid_hash_state % 32767;
if (c2ndx >= c1ndx)
c2ndx++;
nsid->nsid_c2 = 2*c2ndx + 1;
/* generator 3, distinct from 1 and 2 */
a3ndx = ((isc_uint32_t) (NSID_MULT_TABLE_SIZE - 2) *
((nsid_hash_state >> 20) & 0xFFFF)) >> 16;
if (a3ndx >= a1ndx || a3ndx >= a2ndx)
a3ndx++;
if (a3ndx >= a1ndx && a3ndx >= a2ndx)
a3ndx++;
nsid->nsid_a3 = nsid_multiplier_table[a3ndx];
c3ndx = nsid_hash_state % 32766;
if (c3ndx >= c1ndx || c3ndx >= c2ndx)
c3ndx++;
if (c3ndx >= c1ndx && c3ndx >= c2ndx)
c3ndx++;
nsid->nsid_c3 = 2*c3ndx + 1;
nsid->nsid_state =
((nsid_hash_state >> 16) ^ (nsid_hash_state)) & 0xFFFF;
nsid->nsid_usepool = usepool;
if (nsid->nsid_usepool) {
nsid->nsid_pool = isc_mem_get(mctx, 0x10000 * sizeof(isc_uint16_t));
if (nsid->nsid_pool == NULL)
return (ISC_R_NOMEMORY);
for (i = 0; ; i++) {
nsid->nsid_pool[i] = nsid->nsid_state;
nsid->nsid_state =
(((u_long) nsid->nsid_a1 * nsid->nsid_state) +
nsid->nsid_c1) & 0xFFFF;
if (i == 0xFFFF)
break;
}
} else {
nsid->nsid_vtable = isc_mem_get(mctx, NSID_SHUFFLE_TABLE_SIZE *
(sizeof(isc_uint16_t)) );
if (nsid->nsid_vtable == NULL)
return (ISC_R_NOMEMORY);
for (i = 0; i < NSID_SHUFFLE_TABLE_SIZE; i++) {
nsid->nsid_vtable[i] = nsid->nsid_state;
nsid->nsid_state =
(((isc_uint32_t) nsid->nsid_a1 * nsid->nsid_state) +
nsid->nsid_c1) & 0xFFFF;
}
nsid->nsid_state2 = nsid->nsid_state;
}
return (ISC_R_SUCCESS);
}
static void
nsid_destroy(isc_mem_t *mctx, dns_nsid_t *nsid) {
if (nsid->nsid_usepool)
isc_mem_put(mctx, nsid->nsid_pool,
0x10000 * sizeof(isc_uint16_t));
else
isc_mem_put(mctx, nsid->nsid_vtable,
NSID_SHUFFLE_TABLE_SIZE * (sizeof(isc_uint16_t)) );
memset(nsid, 0, sizeof(*nsid));
}
void
dns_dispatch_hash(void *data, size_t len) {
nsid_hash(data, len);
}
lib/dns/include/dns/dispatch.h
+5 -8
View File
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: dispatch.h,v 1.45.2.2.4.5 2007/08/28 07:19:14 tbox Exp $ */
/* $Id: dispatch.h,v 1.45.2.2.4.5.4.1 2008/05/22 21:11:16 each Exp $ */
#ifndef DNS_DISPATCH_H
#define DNS_DISPATCH_H 1
@@ -112,6 +112,9 @@ struct dns_dispatchevent {
* _MAKEQUERY
* The dispatcher can be used to issue queries to other servers, and
* accept replies from them.
*
* _RANDOMPORT
* Allocate UDP port randomly.
*/
#define DNS_DISPATCHATTR_PRIVATE 0x00000001U
#define DNS_DISPATCHATTR_TCP 0x00000002U
@@ -121,6 +124,7 @@ struct dns_dispatchevent {
#define DNS_DISPATCHATTR_NOLISTEN 0x00000020U
#define DNS_DISPATCHATTR_MAKEQUERY 0x00000040U
#define DNS_DISPATCHATTR_CONNECTED 0x00000080U
#define DNS_DISPATCHATTR_RANDOMPORT 0x00000100U
isc_result_t
dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
@@ -437,13 +441,6 @@ dns_dispatch_importrecv(dns_dispatch_t *disp, isc_event_t *event);
* event != NULL
*/
void
dns_dispatch_hash(void *data, size_t len);
/*%<
* Feed 'data' to the dispatch query id generator where 'len' is the size
* of 'data'.
*/
ISC_LANG_ENDDECLS
#endif /* DNS_DISPATCH_H */
lib/dns/resolver.c
+38 -5
View File
@@ -15,7 +15,7 @@
* PERFORMANCE OF THIS SOFTWARE.
*/
/* $Id: resolver.c,v 1.218.2.18.4.77 2008/01/17 23:45:27 tbox Exp $ */
/* $Id: resolver.c,v 1.218.2.18.4.77.2.1 2008/05/22 21:11:15 each Exp $ */
#include <config.h>
@@ -1070,17 +1070,50 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
* A dispatch will be created once the connect succeeds.
*/
} else {
isc_sockaddr_t localaddr;
unsigned int attrs, attrmask;
dns_dispatch_t *disp_base;
attrs = 0;
attrs |= DNS_DISPATCHATTR_UDP;
attrs |= DNS_DISPATCHATTR_RANDOMPORT;
attrmask = 0;
attrmask |= DNS_DISPATCHATTR_UDP;
attrmask |= DNS_DISPATCHATTR_TCP;
attrmask |= DNS_DISPATCHATTR_IPV4;
attrmask |= DNS_DISPATCHATTR_IPV6;
switch (isc_sockaddr_pf(&addrinfo->sockaddr)) {
case PF_INET:
dns_dispatch_attach(res->dispatchv4, &query->dispatch);
case AF_INET:
disp_base = res->dispatchv4;
attrs |= DNS_DISPATCHATTR_IPV4;
break;
case PF_INET6:
dns_dispatch_attach(res->dispatchv6, &query->dispatch);
case AF_INET6:
disp_base = res->dispatchv6;
attrs |= DNS_DISPATCHATTR_IPV6;
break;
default:
result = ISC_R_NOTIMPLEMENTED;
goto cleanup_query;
}
result = dns_dispatch_getlocaladdress(disp_base, &localaddr);
if (result != ISC_R_SUCCESS)
goto cleanup_query;
if (isc_sockaddr_getport(&localaddr) == 0) {
result = dns_dispatch_getudp(res->dispatchmgr,
res->socketmgr,
res->taskmgr,
&localaddr,
4096, 1000, 32768,
16411, 16433,
attrs, attrmask,
&query->dispatch);
if (result != ISC_R_SUCCESS)
goto cleanup_query;
} else
dns_dispatch_attach(disp_base, &query->dispatch);
/*
* We should always have a valid dispatcher here. If we
* don't support a protocol family, then its dispatcher
lib/dns/win32/libdns.def
-2
View File
@@ -121,10 +121,8 @@ dns_decompress_init
dns_decompress_invalidate
dns_decompress_setmethods
dns_decompress_type
dns_dispatch_hash
dns_rdatacallbacks_init
dns_rdatacallbacks_init_stdio
dns_difftuple_create
dns_difftuple_free
dns_difftuple_copy
version
+3 -3
View File
@@ -1,4 +1,4 @@
# $Id: version,v 1.26.2.17.2.31 2008/04/03 00:22:17 each Exp $
# $Id: version,v 1.26.2.17.2.31.4.1 2008/05/22 21:11:13 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=
RELEASEVER=
RELEASETYPE=-P
RELEASEVER=1