Copyright (C) 2000-2003 Internet Software Consortium.
See COPYRIGHT in the source root or http://isc.org/copyright.html for terms.
-$Id: release,v 1.60.18.2 2005/06/24 00:08:13 marka Exp $
+$Id: release,v 1.60.18.3 2006/03/10 04:04:32 marka Exp $
Preparing a bind9 release
find lib -name '*.h' -print | xargs perl util/check-includes.pl
- - Ensure that the JPNIC patch applies cleanly:
+ - Ensure that the JPNIC patch applies cleanly (9.2 and 9.3):
If you don't have the "iconv" library, you need to get it from
http://clisp.cons.org/~haible/packages-libiconv.html and install it.
$ cd ../../.. ; : cd back to top level
$ autoheader ; : regenerate config.h.in
$ autoconf ; : regenerate configure
+ $ (cd bin/dig ; rm host.1 dig.1 ; make host.1 dig.1 ; cvs update host.1 dig.1 )
$ ./configure
$ make
... should cleanly compile
$ old_patch=bind-9.x.y-patch
$ new_patch=bind-9.x.z-patch
$ files=`awk '/^Index:/ && NF == 2 {print $2}' $patchd/$old_patch`
- $ missing=`cvs log -R $files 2>&1 >/dev/null | \
- awk '/^cvs (log|server): nothing known about/ {print $6}'`
+ $ missing=`cvs status $files | awk '/Status: Unknown/ { print $2; }'`
$ sed '/^Index:/,$d' $patchd/$old_patch > $patchd/$new_patch
$ for i in $missing; \
do echo Index: $i; diff -u /dev/null $i; done >> $patchd/$new_patch
$ cvs update -C
$ rm README.idnkit
+ $ make distclean
- Add a marker line like " --- 9.0.0rc10 released ---"
to the CHANGES file.
+++ /dev/null
-
-
-
-
-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: August 13, 2005 T. Lemon
- A. Gustafsson
- Nominum, Inc.
- February 9, 2005
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-09.txt>
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- It is possible for multiple DHCP clients to attempt to update the
- same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
- the clients themselves perform the DNS updates, conflicts can arise.
- To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 1]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
- proposes storing client identifiers in the DNS to unambiguously
- associate domain names with the DHCP clients to which they refer.
- This memo defines a distinct RR type for this purpose for use by DHCP
- clients and servers, the "DHCID" RR.
-
-Table of Contents
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4
- 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4
- 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4
- 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4
- 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2 Informative References . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 2]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
-1. Terminology
-
- 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 [2].
-
-2. Introduction
-
- A set of procedures to allow DHCP [7] clients and servers to
- automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
- in "Resolution of DNS Name Conflicts" [1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same DNS
- name. To resolve such conflicts, "Resolution of DNS Name Conflicts"
- [1] proposes storing client identifiers in the DNS to unambiguously
- associate domain names with the DHCP clients using them. In the
- interest of clarity, it is preferable for this DHCP information to
- use a distinct RR type. This memo defines a distinct RR for this
- purpose for use by DHCP clients or servers, the "DHCID" RR.
-
- In order to avoid exposing potentially sensitive identifying
- information, the data stored is the result of a one-way MD5 [5] hash
- computation. The hash includes information from the DHCP client's
- REQUEST message as well as the domain name itself, so that the data
- stored in the DHCID RR will be dependent on both the client
- identification used in the DHCP protocol interaction and the domain
- name. This means that the DHCID RDATA will vary if a single client
- is associated over time with more than one name. This makes it
- difficult to 'track' a client as it is associated with various domain
- names.
-
- The MD5 hash algorithm has been shown to be weaker than the SHA-1
- algorithm; it could therefore be argued that SHA-1 is a better
- choice. However, SHA-1 is significantly slower than MD5. A
- successful attack of MD5's weakness does not reveal the original data
- that was used to generate the signature, but rather provides a new
- set of input data that will produce the same signature. Because we
- are using the MD5 hash to conceal the original data, the fact that an
- attacker could produce a different plaintext resulting in the same
- MD5 output is not significant concern.
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 3]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
-3.1 DHCID RDATA format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- bytes of binary data. The format of this data and its interpretation
- by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 16-bit identifier type, in network byte order, followed
- by one or more bytes representing the actual identifier:
-
- < 16 bits > DHCP identifier used
- < n bytes > MD5 digest
-
-
-3.2 DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC 2535 [8]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
-
-3.3 The DHCID RR Type Codes
-
- The DHCID RR Type Code specifies what data from the DHCP client's
- request was used as input into the hash function. The type codes are
- defined in a registry maintained by IANA, as specified in Section 7.
- The initial list of assigned values for the type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
- 0x0001 = The data portion from a DHCPv4 client's Client Identifier
- option [9].
- 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
- client's Client Identifier option [10] or the DUID field from a
- DHCPv4 client's Client Identifier option [12]).
-
- 0x0003 - 0xfffe = Available to be assigned by IANA.
-
- 0xffff = RESERVED
-
-3.4 Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the two type bytes with
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 4]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
- some variable-length identifying data.
-
- < type > < data >
-
- The RDATA for all type codes other than 0xffff, which is reserved for
- future expansion, is formed by concatenating the two type bytes and a
- 16-byte MD5 hash value. The input to the hash function is defined to
- be:
-
- data = MD5(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC 2535 [8], section 8.1. The type code and the
- identifier are related as specified in Section 3.3: the type code
- describes the source of the identifier.
-
- When the updater is using the client's link-layer address as the
- identifier, the first two bytes of the DHCID RDATA MUST be zero. To
- generate the rest of the resource record, the updater computes a
- one-way hash using the MD5 algorithm across a buffer containing the
- client's network hardware type, link-layer address, and the FQDN
- data. Specifically, the first byte of the buffer contains the
- network hardware type as it appeared in the DHCP 'htype' field of the
- client's DHCPREQUEST message. All of the significant bytes of the
- chaddr field in the client's DHCPREQUEST message follow, in the same
- order in which the bytes appear in the DHCPREQUEST message. The
- number of significant bytes in the 'chaddr' field is specified in the
- 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified
- above, follows.
-
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two bytes of the
- DHCID RR MUST be 0x0001, in network byte order. The rest of the
- DHCID RR MUST contain the results of computing an MD5 hash across the
- payload of the option, followed by the FQDN. The payload of the
- option consists of the bytes of the option following the option code
- and length.
-
- When the updater is using the DHCPv6 DUID sent by the client in its
- REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
- in network byte order. The rest of the DHCID RR MUST contain the
- results of computing an MD5 hash across the payload of the option,
- followed by the FQDN. The payload of the option consists of the
- bytes of the option following the option code and length.
-
-3.5 Examples
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 5]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
-3.5.1 Example 1
-
- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
- Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- bytes to zero, and performing an MD5 hash computation across a buffer
- containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
- address, and the domain name (represented as specified in
- Section 3.4).
-
- client.example.com. A 10.0.0.1
- client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
-
-
-3.5.2 Example 2
-
- A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
- included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
- in its DHCP request. The server updates the name "chi.example.com"
- on the client's behalf, and uses the DHCP client identifier option
- data as input in forming a DHCID RR. The DHCID RDATA is formed by
- setting the two type bytes to the value 0x0001, and performing an MD5
- hash computation across a buffer containing the seven bytes from the
- client-id option and the FQDN (represented as specified in
- Section 3.4).
-
- chi.example.com. A 10.0.12.99
- chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
-
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts" [1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 6]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
- that the client desires to use to compute a client identity hash, and
- then compare that hash to the data in any DHCID RRs on the name that
- they wish to associate with the client's IP address. If an updater
- discovers DHCID RRs whose RDATA does not match the client identity
- that they have computed, the updater SHOULD conclude that a different
- client is currently associated with the name in question. The
- updater SHOULD then proceed according to the site's administrative
- policy. That policy might dictate that a different name be selected,
- or it might permit the updater to continue.
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security problems
- into the DNS. In order to avoid exposing private information about
- DHCP clients to public scrutiny, a one-way hash is used to obscure
- all client information. In order to make it difficult to 'track' a
- client by examining the names associated with a particular hash
- value, the FQDN is included in the hash computation. Thus, the RDATA
- is dependent on both the DHCP client identification data and on each
- FQDN associated with the client.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones which are exposed to the global Internet. Both DHCP clients
- and servers SHOULD use some form of update authentication (e.g., TSIG
- [11]) when performing DNS updates.
-
-7. IANA Considerations
-
- IANA is requested to allocate an RR type number for the DHCID record
- type.
-
- This specification defines a new number-space for the 16-bit type
- codes associated with the DHCID RR. IANA is requested to establish a
- registry of the values for this number-space.
-
- Three initial values are assigned in Section 3.3, and the value
- 0xFFFF is reserved for future use. New DHCID RR type codes are
- tentatively assigned after the specification for the associated type
- code, published as an Internet Draft, has received expert review by a
- designated expert. The final assignment of DHCID RR type codes is
- through Standards Action, as defined in RFC 2434 [6].
-
-8. Acknowledgements
-
- Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and
- Ralph Droms for their review and suggestions.
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 7]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
-9. References
-
-9.1 Normative References
-
- [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
- DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
- 1992.
-
- [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-9.2 Informative References
-
- [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [8] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
- for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 8]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 1414 Massachusetts Ave.
- Boxborough, MA 01719
- USA
-
- Phone: 978.936.1535
- Email: mjs@cisco.com
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: mellon@nominum.com
-
-
- Andreas Gustafsson
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 9]
-\f
-Internet-Draft The DHCID RR February 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Stapp, et al. Expires August 13, 2005 [Page 10]
-\f
-
+++ /dev/null
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) J. Ihren
-Expires: November 13, 2005 Autonomica AB
- May 12, 2005
-
-
- Minimally Covering NSEC Records and DNSSEC On-line Signing
- draft-ietf-dnsext-dnssec-online-signing-00
-
-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 November 13, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-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 November 13, 2005 [Page 1]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
-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 November 13, 2005 [Page 2]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . 4
- 2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4
- 3. Better Increment & Decrement Functions . . . . . . . . . . . 6
- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
- 5. Security Considerations . . . . . . . . . . . . . . . . . . 7
- 6. Normative References . . . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
- A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8
- Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 3]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
-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 5.
-
- 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.
-
- 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. 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.2. 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).
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 4]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
- 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 SHOULD 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 wsa 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.
-
- 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:
-
- 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 increment or decrement 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
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 5]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
- signatures that must be generated, a zone may wish to limit the
- number of algorithms in its DNSKEY RRset.
-
-3. Better Increment & Decrement Functions
-
- Section 6.2 of RFC4034 defines a strict ordering of DNS names.
- Working backwards from that definition, it should be possible to
- define increment and decrement 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:
-
- 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 increment or decrement functions: it is
- sufficient to test whether any instantiated names fall into the span
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 6]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
- covered by the generated NSEC and, if so, substitute those
- instantiated owner names for the NSEC owner name or next name, as
- appropriate.
-
-4. IANA Considerations
-
- Per RFC4041, IANA should think carefully about the protection of
- their immortal souls.
-
-5. 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 public key 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 increment and decrement 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 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 increment and decrement
- 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
- increment and decrement 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 3
- 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
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 7]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
- 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 [-bis]. The techniques described here actually decrease
- the danger, since the span covered by any NSEC record is smaller than
- before. Choosing better increment and decrement functions will
- further reduce this danger.
-
-6. 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.
-
-
-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
-
-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 November 13, 2005 [Page 8]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
- Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
- Jakob Schlyter, Bill Manning, and Joao Damas.
-
- The key innovation of this document, namely that perfect increment
- and decrement functions are not necessary, arose during a discussion
- among the above-listed people at the RIPE49 meeting in September
- 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 9]
-\f
-Internet-Draft NSEC Epsilon May 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Weiler & Ihren Expires November 13, 2005 [Page 10]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Updates RFC 1034, 1035 Motorola Laboratories
-Expires January 2006 July 2005
-
-
-
- Domain Name System (DNS) Case Insensitivity Clarification
- ------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-06.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 DNSEXT working group at 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 a "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
-
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-Abstract
-
- Domain Name System (DNS) names are "case insensitive". This document
- explains exactly what that means and provides a clear specification
- of the rules. This clarification updates RFCs 1034 and 1035.
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Acknowledgements
-
- The contributions to this document of Rob Austein, Olafur
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
- Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
- are gratefully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Copyright Notice...........................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Case Insensitivity of DNS Labels........................3
- 2.1 Escaping Unusual DNS Label Octets......................3
- 2.2 Example Labels with Escapes............................4
- 3. Name Lookup, Label Types, and CLASS.....................4
- 3.1 Original DNS Label Types...............................5
- 3.2 Extended Label Type Case Insensitivity Considerations..5
- 3.3 CLASS Case Insensitivity Considerations................5
- 4. Case on Input and Output................................6
- 4.1 DNS Output Case Preservation...........................6
- 4.2 DNS Input Case Preservation............................6
- 5. Internationalized Domain Names..........................7
- 6. Security Considerations.................................8
-
- Copyright and Disclaimer...................................9
- Normative References.......................................9
- Informative References....................................10
-
- Changes Between Draft Version.............................11
- -02 to -03 Changes........................................11
- -03 to -04 Changes........................................11
- -04 to -05 Changes........................................11
- -05 to -06 Changes........................................12
-
- Author's Address..........................................13
- Expiration and File Name..................................13
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. Each node in the DNS tree has a name consisting of
- zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
- case insensitive fashion. This document clarifies the meaning of
- "case insensitive" for the DNS. This clarification updates RFCs 1034
- and 1035 [STD 13].
-
- 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].
-
-
-
-2. Case Insensitivity of DNS Labels
-
- DNS was specified in the era of [ASCII]. DNS names were expected to
- look like most host names or Internet email address right halves (the
- part after the at-sign, "@") or be numeric as in the in-addr.arpa
- part of the DNS name space. For example,
-
- foo.example.net.
- aol.com.
- www.gnu.ai.mit.edu.
- or 69.2.0.192.in-addr.arpa.
-
- Case varied alternatives to the above would be DNS names like
-
- Foo.ExamplE.net.
- AOL.COM.
- WWW.gnu.AI.mit.EDU.
- or 69.2.0.192.in-ADDR.ARPA.
-
- However, the individual octets of which DNS names consist are not
- limited to valid ASCII character codes. They are 8-bit bytes and all
- values are allowed. Many applications, however, interpret them as
- ASCII characters.
-
-
-
-2.1 Escaping Unusual DNS Label Octets
-
- In Master Files [STD 13] and other human readable and writable ASCII
- contexts, an escape is needed for the byte value for period (0x2E,
- ".") and all octet values outside of the inclusive range of 0x21
- ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in
- the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- One typographic convention for octets that do not correspond to an
- ASCII printing graphic is to use a back-slash followed by the value
- of the octet as an unsigned integer represented by exactly three
- decimal digits.
-
- The same convention can be used for printing ASCII characters so that
- they will be treated as a normal label character. This includes the
- back-slash character used in this convention itself which can be
- expressed as \092 or \\ and the special label separator period (".")
- which can be expressed as and \046 or \. respectively. It is
- advisable to avoid using a backslash to quote an immediately
- following non-printing ASCII character code to avoid implementation
- difficulties.
-
- A back-slash followed by only one or two decimal digits is undefined.
- A back-slash followed by four decimal digits produces two octets, the
- first octet having the value of the first three digits considered as
- a decimal number and the second octet being the character code for
- the fourth decimal digit.
-
-
-
-2.2 Example Labels with Escapes
-
- The first example below shows embedded spaces and a period (".")
- within a label. The second one show a 5-octet label where the second
- octet has all bits zero, the third is a backslash, and the fourth
- octet has all bits one.
-
- Donald\032E\.\032Eastlake\0323rd.example.
- and a\000\\\255z.example.
-
-
-
-3. Name Lookup, Label Types, and CLASS
-
- The original DNS design decision was made that comparisons on name
- lookup for DNS queries should be case insensitive [STD 13]. That is
- to say, a lookup string octet with a value in the inclusive range of
- 0x41 to 0x5A, the upper case ASCII letters, MUST match the identical
- value and also match the corresponding value in the inclusive range
- 0x61 to 0x7A, the lower case ASCII letters. And a lookup string octet
- with a lower case ASCII letter value MUST similarly match the
- identical value and also match the corresponding value in the upper
- case ASCII letter range.
-
- (Historical Note: the terms "upper case" and "lower case" were
- invented after movable type. The terms originally referred to the
- two font trays for storing, in partitioned areas, the different
- physical type elements. Before movable type, the nearest equivalent
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- terms were "majuscule" and "minuscule".)
-
- One way to implement this rule would be, when comparing octets, to
- subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
- before the comparison. Such an operation is commonly known as "case
- folding" but implementation via case folding is not required. Note
- that the DNS case insensitivity does NOT correspond to the case
- folding specified in [iso-8859-1] or [iso-8859-2]. For example, the
- octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
- contexts, where they are interpreted as the upper and lower case
- version of "Y" with an acute accent, they might.
-
-
-
-3.1 Original DNS Label Types
-
- DNS labels in wire-encoded names have a type associated with them.
- The original DNS standard [RFC 1035] had only two types. ASCII
- labels, with a length of from zero to 63 octets, and indirect (or
- compression) labels which consist of an offset pointer to a name
- location elsewhere in the wire encoding on a DNS message. (The ASCII
- label of length zero is reserved for use as the name of the root node
- of the name tree.) ASCII labels follow the ASCII case conventions
- described herein and, as stated above, can actually contain arbitrary
- byte values. Indirect labels are, in effect, replaced by the name to
- which they point which is then treated with the case insensitivity
- rules in this document.
-
-
-
-3.2 Extended Label Type Case Insensitivity Considerations
-
- DNS was extended by [RFC 2671] to have additional label type numbers
- available. (The only such type defined so far is the BINARY type [RFC
- 2673] which is now Experimental [RFC 3363].)
-
- The ASCII case insensitivity conventions only apply to ASCII labels,
- that is to say, label type 0x0, whether appearing directly or invoked
- by indirect labels.
-
-
-
-3.3 CLASS Case Insensitivity Considerations
-
- As described in [STD 13] and [RFC 2929], DNS has an additional axis
- for data location called CLASS. The only CLASS in global use at this
- time is the "IN" or Internet CLASS.
-
- The handling of DNS label case is not CLASS dependent. With the
- original design of DNS, it was intended that a recursive DNS resolver
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- be able to handle new CLASSes that were unknown at the time of its
- implementation. This requires uniform handling of label case
- insensitivity. Should it become desireable, for example, to allocate
- a CLASS with "case sensitive ASCII labels" for example, it would be
- necessary to allocate a new label type for these labels.
-
-
-
-4. Case on Input and Output
-
- While ASCII label comparisons are case insensitive, [STD 13] says
- case MUST be preserved on output, and preserved when convenient on
- input. However, this means less than it would appear since the
- preservation of case on output is NOT required when output is
- optimized by the use of indirect labels, as explained below.
-
-
-
-4.1 DNS Output Case Preservation
-
- [STD 13] views the DNS namespace as a node tree. ASCII output is as
- if a name was marshaled by taking the label on the node whose name is
- to be output, converting it to a typographically encoded ASCII
- string, walking up the tree outputting each label encountered, and
- preceding all labels but the first with a period ("."). Wire output
- follows the same sequence but each label is wire encoded and no
- periods inserted. No "case conversion" or "case folding" is done
- during such output operations, thus "preserving" case. However, to
- optimize output, indirect labels may be used to point to names
- elsewhere in the DNS answer. In determining whether the name to be
- pointed to, for example the QNAME, is the "same" as the remainder of
- the name being optimized, the case insensitive comparison specified
- above is done. Thus such optimization may easily destroy the output
- preservation of case. This type of optimization is commonly called
- "name compression".
-
-
-
-4.2 DNS Input Case Preservation
-
- Originally, DNS data came from an ASCII Master File as defined in
- [STD 13] or a zone transfer. DNS Dynamic update and incremental zone
- transfers [RFC 1995] have been added as a source of DNS data [RFC
- 2136, 3007]. When a node in the DNS name tree is created by any of
- such inputs, no case conversion is done. Thus the case of ASCII
- labels is preserved if they are for nodes being created. However,
- when a name label is input for a node that already exist in DNS data
- being held, the situation is more complex. Implementations are free
- to retain the case first loaded for such a label or allow new input
- to override the old case or even maintain separate copies preserving
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- the input case.
-
- For example, if data with owner name "foo.bar.example" is loaded and
- then later data with owner name "xyz.BAR.example" is input, the name
- of the label on the "bar.example" node, i.e. "bar", might or might
- not be changed to "BAR" in the DNS stored data or the actual input
- case could be preserved. Thus later retrieval of data stored under
- "xyz.bar.example" in this case can return all data with
- "xyz.BAR.example" or all data with "xyz.bar.example" or even, when
- more than one RR is being returned, a mixture of these two cases.
- This last case is unlikely because optimization of answer length
- through indirect labels tends to cause only copy of the name tail
- ("bar.example" or "BAR.example") to be used for all returned RRs.
- Note that none of this has any effect on the number of completeness
- of the RR set returned, only on the case of the names in the RR set
- returned.
-
- The same considerations apply when inputting multiple data records
- with owner names differing only in case. For example, if an "A"
- record is the first resourced record stored under owner name
- "xyz.BAR.example" and then a second "A" record is stored under
- "XYZ.BAR.example", the second MAY be stored with the first (lower
- case initial label) name or the second MAY override the first so that
- only an upper case initial label is retained or both capitalizations
- MAY be kept in the DNS stored data. In any case, a retrieval with
- either capitalization will retrieve all RRs with either
- capitalization.
-
- Note that the order of insertion into a server database of the DNS
- name tree nodes that appear in a Master File is not defined so that
- the results of inconsistent capitalization in a Master File are
- unpredictable output capitalization.
-
-
-
-5. Internationalized Domain Names
-
- A scheme has been adopted for "internationalized domain names" and
- "internationalized labels" as described in [RFC 3490, 3454, 3491, and
- 3492]. It makes most of [UNICODE] available through a separate
- application level transformation from internationalized domain name
- to DNS domain name and from DNS domain name to internationalized
- domain name. Any case insensitivity that internationalized domain
- names and labels have varies depending on the script and is handled
- entirely as part of the transformation described in [RFC 3454] and
- [RFC 3491] which should be seen for further details. This is not a
- part of the DNS as standardized in STD 13.
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-6. Security Considerations
-
- The equivalence of certain DNS label types with case differences, as
- clarified in this document, can lead to security problems. For
- example, a user could be confused by believing two domain names
- differing only in case were actually different names.
-
- Furthermore, a domain name may be used in contexts other than the
- DNS. It could be used as a case sensitive index into some data base
- or file system. Or it could be interpreted as binary data by some
- integrity or authentication code system. These problems can usually
- be handled by using a standardized or "canonical" form of the DNS
- ASCII type labels, that is, always mapping the ASCII letter value
- octets in ASCII labels to some specific pre-chosen case, either upper
- case or lower case. An example of a canonical form for domain names
- (and also a canonical ordering for them) appears in Section 6 of [RFC
- 4034]. See also [RFC 3597].
-
- Finally, a non-DNS name may be stored into DNS with the false
- expectation that case will always be preserved. For example, although
- this would be quite rare, on a system with case sensitive email
- address local parts, an attempt to store two "RP" records that
- differed only in case would probably produce unexpected results that
- might have security implications. That is because the entire email
- address, including the possibly case sensitive local or left hand
- part, is encoded into a DNS name in a readable fashion where the case
- of some letters might be changed on output as described above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
- 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.
-
-
-
-Normative References
-
- [ASCII] - ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York, 1968.
-
- [RFC 1034, 1035] - See [STD 13].
-
- [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August
- 1996.
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
-
- [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update", November 2000.
-
- [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
- draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
-
- [RFC 4034} - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [STD 13]
- - P. Mockapetris, "Domain names - concepts and facilities", RFC
- 1034, November 1987.
- - P. Mockapetris, "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Informative References
-
- [ISO 8859-1] - International Standards Organization, Standard for
- Character Encodings, Latin-1.
-
- [ISO 8859-2] - International Standards Organization, Standard for
- Character Encodings, Latin-2.
-
- [RFC 1591] - J. Postel, "Domain Name System Structure and
- Delegation", March 1994.
-
- [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
- June 1999.
-
- [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
- Name System (DNS) IANA Considerations", September 2000.
-
- [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
- 1999.
-
- [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
- August 1999.
-
- [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of
- Foo", 1 April 2001.
-
- [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
- the Domain Name System (DNS)", RFC 3363, August 2002.
-
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
- Internationalized String ("stringprep")", December 2002.
-
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names (IDN)", March 2003.
-
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)", March
- 2003.
-
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",
- <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Changes Between Draft Version
-
- RFC Editor: The following summaries of changes between draft versions
- are to be removed before publication.
-
-
-
--02 to -03 Changes
-
- The following changes were made between draft version -02 and -03:
-
- 1. Add internationalized domain name section and references.
-
- 2. Change to indicate that later input of a label for an existing DNS
- name tree node may or may not be normalized to the earlier input or
- override it or both may be preserved.
-
- 3. Numerous minor wording changes.
-
-
-
--03 to -04 Changes
-
- The following changes were made between draft versions -03 and -04:
-
- 1. Change to conform to the new IPR, Copyright, etc., notice
- requirements.
-
- 2. Change in some section headers for clarity.
-
- 3. Drop section on wildcards.
-
- 4. Add emphasis on loss of case preservation due to name compression.
-
- 5. Add references to RFCs 1995 and 3092.
-
-
-
--04 to -05 Changes
-
- The following changes were made between draft versions -04 and -05:
-
- 1. More clearly state that this draft updates RFCs 1034, 1035 [STD
- 13].
-
- 2. Add informative references to ISO 8859-1 and ISO 8859-2.
-
- 3. Fix hyphenation and capitalization nits.
-
-
-
-
-D. Eastlake 3rd [Page 11]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
--05 to -06 Changes
-
- The following changes were made between draft version -05 and -06.
-
- 1. Add notation to the RFC Editor that the draft version change
- summaries are to be removed before RFC publication.
-
- 2. Additional text explaining why labe case insensitivity is CLASS
- independent.
-
- 3. Changes and additional text clarifying that the fact that
- inconsistent case in data loaded into DNS may result in
- unpredicatable or inconsistent case in DNS storage but has no effect
- on the completeness of RR sets retrieved.
-
- 4. Add reference to [RFC 3363] and update reference to [RFC 2535] to
- be to [RFC 4034].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 12]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 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 January 2006.
-
- Its file name is draft-ietf-dnsext-insensitive-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 13]
-\f
+++ /dev/null
-
-
-
-Network Working Group B. Laurie
-Internet-Draft G. Sisson
-Expires: December 3, 2005 Nominet
- R. Arends
- Telematica Instituut
- june 2005
-
-
- DNSSEC Hash Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-02
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on December 3, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be
- used to provide authenticated denial of existence of DNS ownernames
- and types; however, it permits any user to traverse a zone and obtain
- a listing of all ownernames.
-
- A complete zone file can be used either directly as a source of
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 1]
-\f
-Internet-Draft nsec3 june 2005
-
-
- probable e-mail addresses for spam, or indirectly as a key for
- multiple WHOIS queries to reveal registrant data which many
- registries (particularly in Europe) may be under strict legal
- obligations to protect. Many registries therefore prohibit copying
- of their zone file; however the use of NSEC RRs renders policies
- unenforceable.
-
- This document proposes a scheme which obscures original ownernames
- while permitting authenticated denial of existence of non-existent
- names. Non-authoritative delegation point NS RR types may be
- excluded.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
- 2.1 NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 5
- 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 6
- 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 6
- 2.1.3 The Iterations Field . . . . . . . . . . . . . . . . . 7
- 2.1.4 The Salt Length Field . . . . . . . . . . . . . . . . 7
- 2.1.5 The Salt Field . . . . . . . . . . . . . . . . . . . . 7
- 2.1.6 The Next Hashed Ownername Field . . . . . . . . . . . 7
- 2.1.7 The list of Type Bit Map(s) Field . . . . . . . . . . 8
- 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 9
- 3. Creating Additional NSEC3 RRs for Empty Non Terminals . . . . 9
- 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 10
- 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 10
- 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 11
- 6.1 Delegation Points . . . . . . . . . . . . . . . . . . . . 11
- 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
- 6.2 Proving Nonexistence . . . . . . . . . . . . . . . . . . . 12
- 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 13
- 6.4.1 Avoiding Hash Collisions during generation . . . . . . 14
- 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 14
- 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 14
- 7. Performance Considerations . . . . . . . . . . . . . . . . . . 15
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
- 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
- 10.1 Normative References . . . . . . . . . . . . . . . . . . . 16
- 10.2 Informative References . . . . . . . . . . . . . . . . . . 17
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
- A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 18
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 2]
-\f
-Internet-Draft nsec3 june 2005
-
-
- B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 23
- B.1 answer . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- B.1.1 Authenticating the Example DNSKEY RRset . . . . . . . 25
- B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 26
- B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 28
- B.3.1 No Data Error, Empty Non-Terminal . . . . . . . . . . 29
- B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 30
- B.5 Referral to Unsigned Zone using Opt-In . . . . . . . . . . 31
- B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 32
- B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 34
- B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 35
- Intellectual Property and Copyright Statements . . . . . . . . 37
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 3]
-\f
-Internet-Draft nsec3 june 2005
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) introduced the NSEC Resource
- Record (RR) for authenticated denial of existence. This document
- introduces a new RR as an alternative to NSEC that provides measures
- against zone traversal and allows for gradual expansion of
- delegation-centric zones.
-
-1.1 Rationale
-
- The DNS Security Extensions included the NSEC RR to provide
- authenticated denial of existence. Though the NSEC RR meets the
- requirements for authenticated denial of existence, it introduced a
- side-effect in that the contents of a zone can be enumerated. This
- property introduces undesired policy issues.
-
- A second problem was the requirement that the existence of all record
- types in a zone - including delegation point NS record types - must
- be accounted for, despite the fact that delegation point NS RRsets
- are not authoritative and not signed. This requirement has a side-
- effect that the overhead of delegation-centric signed zones is not
- related to the increase in security of subzones. This requirement
- does not allow delegation-centric zones size to grow in relation to
- the growth of signed subzones.
-
- In the past, solutions have been proposed as a measure against these
- side effects but at the time were regarded as secondary over the need
- to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter)
- a graceful transition path to future enhancements is introduced,
- while current DNSSEC deployment can continue. This document presents
- the NSEC3 Resource Record which mitigates these issues with the NSEC
- RR.
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs
- that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308
- [RFC2308].
-
-1.2 Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-1.3 Terminology
-
- In this document the term "original ownername" refers to a standard
- ownername. Because this proposal uses the result of a hash function
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 4]
-\f
-Internet-Draft nsec3 june 2005
-
-
- over the original (unmodified) ownername, this result is referred to
- as "hashed ownername".
-
- "Canonical ordering of the zone" means the order in which hashed
- ownernames are arranged according to their numerical value, treating
- the leftmost (lowest numbered) byte as the most significant byte.
-
-2. The NSEC3 Resource Record
-
- The NSEC3 RR provides Authenticated Denial of Existence for DNS
- Resource Record Sets.
-
- The NSEC3 Resource Record lists RR types present at the NSEC3 RR's
- original ownername. It includes the next hashed ownername in the
- canonical ordering of the zone. The complete set of NSEC3 RRs in a
- zone indicates which RRsets exist for the original ownername of the
- RRset and form a chain of hashed ownernames in the zone. This
- information is used to provide authenticated denial of existence for
- DNS data, as described in RFC 4035 [RFC4035]. Unsigned delegation
- point NS RRsets can optionally be excluded. To provide protection
- against zone traversal, the ownernames used in the NSEC3 RR are
- cryptographic hashes of the original ownername prepended to the name
- of the zone. The NSEC3 RR indicates which hash function is used to
- construct the hash, which salt is used, and how many iterations of
- the hash function are performed over the original ownername.
-
- The ownername for the NSEC3 RR is the base32 encoding of the hashed
- ownername.
-
- The type value for the NSEC3 RR is XX.
-
- The NSEC3 RR RDATA format is class independent.
-
- The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
- field. This is in the spirit of negative caching [RFC2308].
-
-2.1 NSEC3 RDATA Wire Format
-
- The RDATA of the NSEC3 RR is as shown below:
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 5]
-\f
-Internet-Draft nsec3 june 2005
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |A|Hash Function| Iterations |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Salt Length | Salt /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Next Hashed Ownername /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Maps /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1 The Authoritative Only Flag Field
-
- The Authoritative Only Flag field indicates whether the Type Bit Maps
- include delegation point NS record types.
-
- If the flag is set to 1, the NS RR type bit for a delegation point
- ownername SHOULD be clear when the NSEC3 RR is generated. The NS RR
- type bit MUST be ignored during processing of the NSEC3 RR. The NS
- RR type bit has no meaning in this context (it is not authoritative),
- hence the NSEC3 does not contest the existence of a NS RRset for this
- ownername. When a delegation is not secured, there exist no DS RR
- type nor any other authoritative types for this delegation, hence the
- unsecured delegation has no NSEC3 record associated. Please see the
- Special Consideration section for implications for unsigned
- delegations.
-
- If the flag is set to 0, the NS RR type bit for a delegation point
- ownername MUST be set if the NSEC3 covers a delegation, even though
- the NS RR itself is not authoritative. This implies that all
- delegations, signed or unsigned, have an NSEC3 record associated.
- This behaviour is identical to NSEC behaviour.
-
-2.1.2 The Hash Function Field
-
- The Hash Function field identifies the cryptographic hash function
- used to construct the hash-value.
-
- This document defines Value 1 for SHA-1 and Value 127 for
- experimental. All other values are reserved.
-
- On reception, a resolver MUST discard an NSEC3 RR with an unknown
- hash function value.
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 6]
-\f
-Internet-Draft nsec3 june 2005
-
-
-2.1.3 The Iterations Field
-
- The Iterations field defines the number of times the hash has been
- iterated. More iterations results in greater resiliency of the hash
- value against dictionary attacks, but at a higher cost for both the
- server and resolver.
-
-2.1.4 The Salt Length Field
-
- The salt length field defines the length of the salt in octets.
-
-2.1.5 The Salt Field
-
- The Salt field is not present when the Salt Length Field has a value
- of 0.
-
- The Salt field is prepended to the original ownername before hashing
- in order to defend against precalculated dictionary attacks.
-
- The salt is also prepended during iterations of the hash function.
-
- Note that although it is theoretically possible to cover the entire
- possible ownername space with different salt values, it is
- computationally infeasible to do so, and so there MUST be at least
- one salt which is the same for all NSEC3 records. This means that no
- matter what name is asked for in a query, it is guaranteed to be
- possible to find a covering NSEC3 record. Note that this does not
- preclude the use of two different salts at the same time - indeed
- this may well occur naturally, due to rolling the salt value
- periodically.
-
- The salt value SHOULD be changed from time to time - this is to
- prevent the use of a precomputed dictionary to reduce the cost of
- enumeration.
-
-2.1.6 The Next Hashed Ownername Field
-
- The Next Hashed Ownername field contains the hash of the ownername of
- the next RR in the canonical ordering of the hashed ownernames of the
- zone. The value of the Next Hashed Ownername Field in the last NSEC3
- record in the zone is the same as the ownername of the first NSEC3 RR
- in the zone in canonical order.
-
- Hashed ownernames of RRsets not authoritative for the given zone
- (such as glue records) MUST NOT be listed in the Next Hashed
- Ownername unless at least one authoritative RRset exists at the same
- ownername.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 7]
-\f
-Internet-Draft nsec3 june 2005
-
-
- Note that the Next Hashed Ownername field is not encoded, unlike the
- NSEC3 RR's ownername. It is the unmodified binary hash value.
-
-2.1.7 The list of Type Bit Map(s) Field
-
- The Type Bit Maps field identifies the RRset types which exist at the
- NSEC3 RR's ownername.
-
- The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
- generation, and MUST be ignored during processing.
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that
- has at least one active RR type is encoded using a single octet
- window number (from 0 to 255), a single octet bitmap length (from 1
- to 32) indicating the number of octets used for the window block's
- bitmap, and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC3 RR RDATA in increasing numerical
- order.
-
- "|" denotes concatenation
-
- Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRset of that type is present for the NSEC3
- RR's ownername. If a bit is set to 0, it indicates that no RRset of
- that type is present for the NSEC3 RR's ownername.
-
- The RR type 2 (NS) is authoritative at the apex of a zone and is not
- authoritative at delegation points. If the Authoritative Only Flag
- is set to 1, the delegation point NS RR type MUST NOT be included in
- the type bit maps. If the Authoritative Only Flag is set to 0, the
- NS RR type at a delegation point MUST be included in the type bit
- maps.
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929
- [RFC2929] (section 3.1) or within the range reserved for assignment
- only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 8]
-\f
-Internet-Draft nsec3 june 2005
-
-
- appear in zone data. If encountered, they must be ignored upon
- reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of each block's
- bitmap is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
- be interpreted as zero octets.
-
-2.2 The NSEC3 RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Authoritative Only Field is represented as an unsigned decimal
- integer. The value are either 0 or 1.
-
- The Hash field is presented as the name of the hash or as an unsigned
- decimal integer. The value has a maximum of 127.
-
- The Iterations field is presented as an unsigned decimal integer.
-
- The Salt Length field is not presented.
-
- The Salt field is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is not allowed within the sequence.
- The Salt Field is represented as 00 when the Salt Length field has
- value 0.
-
- The Next Hashed Ownername field is represented as a sequence of case-
- insensitive base32 digits. Whitespace is allowed within the
- sequence.
-
- The List of Type Bit Map(s) Field is represented as a sequence of RR
- type mnemonics. When the mnemonic is not known, the TYPE
- representation as described in RFC 3597 [RFC3597] (section 5) MUST be
- used.
-
-3. Creating Additional NSEC3 RRs for Empty Non Terminals
-
- In order to prove the non-existence of a record that might be covered
- by a wildcard, it is necessary to prove the existence of its closest
- encloser. A closest encloser might be an Empty Non Terminal.
-
- Additional NSEC3 RRs are synthesized which cover every existing
- intermediate label level. Additional NSEC3 RRs are identical in
- format to NSEC3 RRs that cover existing RRs in the zone. The
- difference is that the type-bit-maps only indicate the existence of
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 9]
-\f
-Internet-Draft nsec3 june 2005
-
-
- an NSEC3 RR type and an RRSIG RR type.
-
-4. Calculation of the Hash
-
- Define H(x) to be the hash of x using the hash function selected by
- the NSEC3 record and || to indicate concatenation. Then define:
-
- IH(salt,x,0)=H(x || salt)
-
- IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
-
- Then the calculated hash of an ownername is
- IH(salt,ownername,iterations-1), where the ownername is the canonical
- form.
-
- The canonical form of the ownername is the wire format of the
- ownername where:
- 1. The ownername is fully expanded (no DNS name compression) and
- fully qualified;
- 2. All uppercase US-ASCII letters are replaced by the corresponding
- lowercase US-ASCII letters;
- 3. If the ownername is a wildcard name, the ownername is in its
- original unexpanded form, including the "*" label (no wildcard
- substitution);
-
-5. Including NSEC3 RRs in a Zone
-
- Each owner name in the zone which has authoritative data or a secured
- delegation point NS RRset MUST have an NSEC3 resource record.
-
- An unsecured delegation point NS RRset MAY have an NSEC3 resource
- record. This is different from NSEC records where an unsecured
- delegation point NS RRset MUST have an NSEC record.
-
- The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
- value field in the zone SOA RR.
-
- The type bitmap of every NSEC3 resource record in a signed zone MUST
- indicate the presence of both the NSEC3 RR type itself and its
- corresponding RRSIG RR type.
-
- The bitmap for the NSEC3 RR at a delegation point requires special
- attention. Bits corresponding to the delegation NS RRset and any
- RRsets for which the parent zone has authoritative data MUST be set;
- bits corresponding to any non-NS RRset for which the parent is not
- authoritative MUST be clear.
-
- The following steps describe the proper construction of NSEC3
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 10]
-\f
-Internet-Draft nsec3 june 2005
-
-
- records.
- 1. For each unique original owner name in the zone, add an NSEC3
- RRset. This includes NSEC3 RRsets for unsigned delegation point
- NS RRsets, unless the policy is to have Authoritative Only NSEC3
- RRsets. The ownername of the NSEC3 RR is the hashed equivalent
- of the original owner name, prepended to the zone name.
- 2. For each RRset at the original owner, set the corresponding bit
- in the type bit map.
- 3. If the difference in number of labels between the apex and the
- original ownername is greater then 1, additional NSEC3s need to
- be added for every empty non-terminal between the apex and the
- original ownername.
- 4. Sort the set of NSEC3 RRs.
- 5. In each NSEC3 RR, insert the Next Hashed Ownername. The Next
- Hashed Ownername of the last NSEC3 in the zone contains the value
- of the hashed ownername of the first NSEC3 in the zone.
- 6. If the policy is to have authoritative only, set the
- Authoritative Only bit in those NSEC3 RRs that cover unsecured
- delegation points.
-
-6. Special Considerations
-
- The following paragraphs clarify specific behaviour explain special
- considerations for implementations.
-
-6.1 Delegation Points
-
- This proposal introduces the Authoritative Only Flag which indicates
- whether non authoritative delegation point NS records are included in
- the type bit Maps. As discussed in paragraph 2.1.1, a flag value of
- 0 indicates that the interpretation of the type bit maps is identical
- to NSEC records.
-
- The following subsections describe behaviour when the flag value is
- 1.
-
-6.1.1 Unsigned Delegations
-
- Delegation point NS records are not authoritative. They are
- authoritative in the delegated zone. No other data exists at the
- ownername of an unsigned delegation point.
-
- Since no authoritative data exist at this ownername, it is excluded
- from the NSEC3 chain. This is an optimization, since it relieves the
- zone of including an NSEC3 record and its associated signature for
- this name.
-
- An NSEC3 that denies existence of ownernames between X and X' with
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 11]
-\f
-Internet-Draft nsec3 june 2005
-
-
- the Authoritative Only Flag set to 1 can not be used to prove the
- presence or the absence of delegation point NS records for unsigned
- delegations in the interval (X, X'). The Authoritative Only Flag
- effectively states No Contest on the presence of delegation point NS
- resource records.
-
- Since proof is absent, there exists a new attack vector. Unsigned
- delegation point NS records can be deleted during a man in the middle
- attack, effectively denying existence of the delegation. This is a
- form of Denial of Service, where the victim has no information it is
- under attack, since all signatures are valid and the fabricated
- response form is a known type of response.
-
- The only possible mitigation is to either not use this method, hence
- proving existence or absence of unsigned delegations, or to sign all
- delegations, regardless of whether the delegated zone is signed or
- not.
-
- A second attack vector exists in that an adversary is able to
- successfully fabricate an (unsigned) response claiming a nonexistent
- delegation exists.
-
- The only possible mitigation is to mandate the signing of all
- delegations.
-
-6.2 Proving Nonexistence
-
- If a wildcard resource record appears in a zone, its asterisk label
- is treated as a literal symbol and is treated in the same way as any
- other ownername for purposes of generating NSEC3 RRs. RFC 4035
- [RFC4035] describes the impact of wildcards on authenticated denial
- of existence.
-
- In order to prove there exist no RRs for a domain, as well as no
- source of synthesis, an RR must be shown for the closest encloser,
- and non-existence must be shown for all closer labels and for the
- wildcard at the closest encloser.
-
- This can be done as follows. If the QNAME in the query is
- omega.alfa.beta.example, and the closest encloser is beta.example
- (the nearest ancestor to omega.alfa.beta.example), then the server
- should return an NSEC3 that demonstrates the nonexistence of
- alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
- *.beta.example, and an NSEC3 that demonstrates the existence of
- beta.example. This takes between one and three NSEC3 records, since
- a single record can, by chance, prove more than one of these facts.
-
- When a verifier checks this response, then the existence of
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 12]
-\f
-Internet-Draft nsec3 june 2005
-
-
- beta.example together with the non-existence of alfa.beta.example
- proves that the closest encloser is indeed beta.example. The non-
- existence of *.beta.example shows that there is no wildcard at the
- closest encloser, and so no source of synthesis for
- omega.alfa.beta.example. These two facts are sufficient to satisfy
- the resolver that the QNAME cannot be resolved.
-
- In practice, since the NSEC3 owner and next names are hashed, if the
- server responds with an NSEC3 for beta.example, the resolver will
- have to try successively longer names, starting with example, moving
- to beta.example, alfa.beta.example, and so on, until one of them
- hashes to a value that matches the interval (but not the ownername
- nor next owner name) of one of the returned NSEC3s (this name will be
- alfa.beta.example). Once it has done this, it knows the closest
- encloser (i.e. beta.example), and can then easily check the other two
- required proofs.
-
- Note that it is not possible for one of the shorter names tried by
- the resolver to be denied by one of the returned NSEC3s, since, by
- definition, all these names exist and so cannot appear within the
- range covered by an NSEC3. Note, however, that the first name that
- the resolver tries MUST be the apex of the zone, since names above
- the apex could be denied by one of the returned NSEC3s.
-
-6.3 Salting
-
- Augmenting original ownernames with salt before hashing increases the
- cost of a dictionary of pre-generated hash-values. For every bit of
- salt, the cost of the dictionary doubles. The NSEC3 RR can use a
- maximum of 2040 bits of salt, multiplying the cost by 2^2040.
-
- There MUST be a complete set of NSEC3s for the zone using the same
- salt value. The salt value for each NSEC3 RR MUST be equal for a
- single version of the zone.
-
- The salt SHOULD be changed every time the zone is resigned to prevent
- precomputation using a single salt.
-
-6.4 Hash Collision
-
- Hash collisions occur when different messages have the same hash
- value. The expected number of domain names needed to give a 1 in 2
- chance of a single collision is about 2^(n/2) for a hash of length n
- bits (i.e. 2^80 for SHA-1). Though this probability is extremely
- low, the following paragraphs deal with avoiding collisions and
- assessing possible damage in the event of an attack using hash
- collisions.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 13]
-\f
-Internet-Draft nsec3 june 2005
-
-
-6.4.1 Avoiding Hash Collisions during generation
-
- During generation of NSEC3 RRs, hash values are supposedly unique.
- In the (academic) case of a collision occurring, an alternative salt
- SHOULD be chosen and all hash values SHOULD be regenerated.
-
- If hash values are not regenerated on collision, the NSEC3 RR MUST
- list all authoritative RR types that exist for both owners, to avoid
- a replay attack, spoofing an existing type as non-existent.
-
-6.4.2 Second Preimage Requirement Analysis
-
- A cryptographic hash function has a second-preimage resistance
- property. The second-preimage resistance property means that it is
- computationally infeasible to find another message with the same hash
- value as a given message, i.e. given preimage X, to find a second
- preimage X' <> X such that hash(X) = hash(X'). The work factor for
- finding a second preimage is of the order of 2^160 for SHA-1. To
- mount an attack using an existing NSEC3 RR, an adversary needs to
- find a second preimage.
-
- Assuming an adversary is capable of mounting such an extreme attack,
- the actual damage is that a response message can be generated which
- claims that a certain QNAME (i.e. the second pre-image) does exist,
- while in reality QNAME does not exist (a false positive), which will
- either cause a security aware resolver to re-query for the non-
- existent name, or to fail the initial query. Note that the adversary
- can't mount this attack on an existing name but only on a name that
- the adversary can't choose and does not yet exist.
-
-6.4.3 Possible Hash Value Truncation Method
-
- The previous sections outlined the low probability and low impact of
- a second-preimage attack. When impact and probability are low, while
- space in a DNS message is costly, truncation is tempting. Truncation
- might be considered to allow for shorter ownernames and rdata for
- hashed labels. In general, if a cryptographic hash is truncated to n
- bits, then the expected number of domains required to give a 1 in 2
- probability of a single collision is approximately 2^(n/2) and the
- work factor to produce a second preimage resistance is 2^n.
-
- An extreme hash value truncation would be truncating to the shortest
- possible unique label value. Considering that hash values are
- presented in base32, which represents 5 bits per label character,
- truncation must be done on a 5 bit boundary. This would be unwise,
- since the work factor to produce collisions would then approximate
- the size of the zone.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 14]
-\f
-Internet-Draft nsec3 june 2005
-
-
- Though the mentioned truncation can be maximized to a certain
- extreme, the probability of collision increases exponentially for
- every truncated bit. Given the low impact of hash value collisions
- and limited space in DNS messages, the balance between truncation
- profit and collision damage may be determined by local policy. Of
- course, the size of the corresponding RRSIG RR is not reduced, so
- truncation is of limited benefit.
-
- Truncation could be signalled simply by reducing the length of the
- first label in the ownername. Note that there would have to be a
- corresponding reduction in the length of the Next Hashed Ownername
- field.
-
-7. Performance Considerations
-
- Iterated hashes will obviously impose a performance penalty on both
- authoritative servers and resolvers. Therefore, the number of
- iterations should be carefully chosen. In particular it should be
- noted that a high value for iterations gives an attacker a very good
- denial of service attack, since the attacker need not bother to
- verify the results of their queries, and hence has no performance
- penalty of his own.
-
- On the other hand, nameservers with low query rates and limited
- bandwidth are already subject to a bandwidth based denial of service
- attack, since responses are typically an order of magnitude larger
- than queries, and hence these servers may choose a high value of
- iterations in order to increase the difficulty of offline attempts to
- enumerate their namespace without significantly increasing their
- vulnerability to denial of service attacks.
-
-8. IANA Considerations
-
- IANA has to create a new registry for NSEC3 Hash Functions. The
- range for this registry is 0-127. Value 0 is the identity function.
- Value 1 is SHA-1. Values 2-126 are Reserved For Future Use. Value
- 127 is marked as Experimental.
-
-9. Security Considerations
-
- The NSEC3 records are still susceptible to dictionary attacks (i.e.
- the attacker retrieves all the NSEC3 records, then calculates the
- hashes of all likely domain names, comparing against the hashes found
- in the NSEC3 records, and thus enumerating the zone). These are
- substantially more expensive than traversing the original NSEC
- records would have been, and in any case, such an attack could also
- be used directly against the name server itself by performing queries
- for all likely names, though this would obviously be more detectable.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 15]
-\f
-Internet-Draft nsec3 june 2005
-
-
- The expense of this off-line attack can be chosen by setting the
- number of iterations in the NSEC3 RR.
-
- High-value domains are also susceptible to a precalculated dictionary
- attack - that is, a list of hashes for all likely names is computed
- once, then NSEC3 is scanned periodically and compared against the
- precomputed hashes. This attack is prevented by changing the salt on
- a regular basis.
-
- Walking the NSEC3 RRs will reveal the total number of records in the
- zone, and also what types they are. This could be mitigated by
- adding dummy entries, but certainly an upper limit can always be
- found.
-
- Hash collisions may occur. If they do, it will be impossible to
- prove the non-existence of the colliding domain - however, this is
- fantastically unlikely, and, in any case, DNSSEC already relies on
- SHA-1 to not collide.
-
-10. References
-
-10.1 Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2308, March 1998.
-
- [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42,
- RFC 2929, September 2000.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 16]
-\f
-Internet-Draft nsec3 june 2005
-
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-10.2 Informative References
-
- [I-D.ietf-dnsext-trustupdate-threshold]
- Ihren, J., "An In-Band Rollover Mechanism and an Out-Of-
- Band Priming Method for DNSSEC Trust Anchors.",
- draft-ietf-dnsext-trustupdate-threshold-00 (work in
- progress), October 2004.
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2418] Bradner, S., "IETF Working Group Guidelines and
- Procedures", BCP 25, RFC 2418, September 1998.
-
-
-Authors' Addresses
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London W3 7LR
- England
-
- Phone: +44 (20) 8735 0686
- Email: ben@algroup.co.uk
-
-
- Geoffrey Sisson
- Nominet
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 17]
-\f
-Internet-Draft nsec3 june 2005
-
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- 7523 XC Enschede
- The Netherlands
-
- Phone: +31 (53) 485 0485
- Email: roy.arends@telin.nl
-
-Appendix A. Example Zone
-
- This is a zone showing its NSEC3 records. They can also be used as
- test vectors for the hash algorithm.
-
-
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600 )
- 3600 RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- 3600 NS ns1.example.
- 3600 NS ns2.example.
- 3600 RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
- 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
- NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
- S/o/g5C8VM6ftQ== )
- 3600 DNSKEY 257 3 5 (
- AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
- cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
- zsYKWJ7BvR2894hX
- ) ; Key ID = 21960
- 3600 DNSKEY 256 3 5 (
- AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
- 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
- ExXT48OGGdbfIme5
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 18]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ) ; Key ID = 62699
- 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
- xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
- mTkunTYzqWJrmQ== )
- 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
- 20050612112304 21960 example.
- SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
- ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
- 3w7ZY2UWyYIvpw== )
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2
- NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
- Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
- sb7KfbaUo/vzAg== )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
- ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
- MEFQmc/gEuxojA== )
- a.example. 3600 IN NS ns1.a.example.
- 3600 IN NS ns2.a.example.
- 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
- 766A6A4837206C )
- 3600 RRSIG DS 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
- cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
- 0kx7rGKTc3RQDA== )
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
- ai.example. 3600 IN A 192.0.2.9
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
- 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
- ZXW5S+1VjMZYzQ== )
- 3600 HINFO "KLH-10" "ITS"
- 3600 RRSIG HINFO 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 19]
-\f
-Internet-Draft nsec3 june 2005
-
-
- 20050612112304 62699 example.
- AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
- tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
- VGNmbgPnqDVPiA== )
- 3600 AAAA 2001:db8:0:0:0:0:f00:baa9
- 3600 RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
- ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
- l5/UqLCJJ9BDMg== )
- b.example. 3600 IN NS ns1.b.example.
- 3600 IN NS ns2.b.example.
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- gmnfcccja7wkax3iv26bs75myptje3qk
- MX DNSKEY NS SOA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
- C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
- MOiKMSHozVebqw== )
- gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
- DS NS NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
- ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
- OwQBGbOegrW/Zw== )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- kcll7fqfnisuhfekckeeqnmbbd4maanu
- NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
- IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
- 94Zbq3k8lgdpZA== )
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
- deadbeaf
- n42hbhnjj333xdxeybycax5ufvntux5d
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 20]
-\f
-Internet-Draft nsec3 june 2005
-
-
- IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
- TOLtc5jPrkL4zQ== )
- n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- nimwfwcnbeoodmsc6npv3vuaagaevxxu
- A NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
- 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
- xFPFGRIW3wKnrA== )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- vhgwr2qgykdkf4m6iv6vkagbxozphazr
- HINFO A AAAA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
- z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
- jL33Wm1p07TBdw== )
- ns1.example. 3600 A 192.0.2.1
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
- BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
- nWWLepz1PjjShQ== )
- ns2.example. 3600 A 192.0.2.2
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
- P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
- AkeTJu3J3auUiA== )
- vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw
- HINFO A AAAA NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
- kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
- 5SNSHIyfpfsi6A== )
- *.w.example. 3600 MX 1 ai.example.
- 3600 RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
- xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
- gQlgxEwhvQDEaQ== )
- x.w.example. 3600 MX 1 xx.example.
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 21]
-\f
-Internet-Draft nsec3 june 2005
-
-
- 3600 RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
- lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
- U9VazOa1KEIq1w== )
- x.y.w.example. 3600 MX 1 xx.example.
- 3600 RRSIG MX 5 4 3600 20050712112304 (
- 20050612112304 62699 example.
- aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
- uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
- 9VrQvJjwbllAfA== )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
- A NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
- ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
- oorBv4xkb0flXw== )
- xx.example. 3600 A 192.0.2.10
- 3600 RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
- tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
- cxwCXWj82GVGdw== )
- 3600 HINFO "KLH-10" "TOPS-20"
- 3600 RRSIG HINFO 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
- OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
- KMf4DgNBDj+dIQ== )
- 3600 AAAA 2001:db8:0:0:0:0:f00:baaa
- 3600 RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
- w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
- rzKKwb8J04/ILw== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 22]
-\f
-Internet-Draft nsec3 june 2005
-
-
-Appendix B. Example Responses
-
- The examples in this section show response messages using the signed
- zone example in Appendix A.
-
-B.1 answer
-
- A successful query to an authoritative server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 23]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- x.w.example. IN MX
-
- ;; Answer
- x.w.example. 3600 IN MX 1 xx.example.
- x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
- lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
- U9VazOa1KEIq1w== )
-
- ;; Authority
- example. 3600 IN NS ns1.example.
- example. 3600 IN NS ns2.example.
- example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
-
- ;; Additional
- xx.example. 3600 IN A 192.0.2.10
- xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
- tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
- cxwCXWj82GVGdw== )
- xx.example. 3600 IN AAAA 2001:db8::f00:baaa
- xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
- w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
- rzKKwb8J04/ILw== )
- ns1.example. 3600 IN A 192.0.2.1
- ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
- BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
- nWWLepz1PjjShQ== )
- ns2.example. 3600 IN A 192.0.2.2
- ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
- P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
- AkeTJu3J3auUiA== )
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 24]
-\f
-Internet-Draft nsec3 june 2005
-
-
- The query returned an MX RRset for "x.w.example". The corresponding
- RRSIG RR indicates that the MX RRset was signed by an "example"
- DNSKEY with algorithm 5 and key tag 62699. The resolver needs the
- corresponding DNSKEY RR in order to authenticate this answer. The
- discussion below describes how a resolver might obtain this DNSKEY
- RR.
-
- The RRSIG RR indicates the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG RR's labels field value of 3 indicates that the
- answer was not the result of wildcard expansion. The "x.w.example"
- MX RRset is placed in canonical form, and, assuming the current time
- falls between the signature inception and expiration dates, the
- signature is authenticated.
-
-B.1.1 Authenticating the Example DNSKEY RRset
-
- This example shows the logical authentication process that starts
- from a configured root DNSKEY RRset (or DS RRset) and moves down the
- tree to authenticate the desired "example" DNSKEY RRset. Note that
- the logical order is presented for clarity. An implementation may
- choose to construct the authentication as referrals are received or
- to construct the authentication chain only after all RRsets have been
- obtained, or in any other combination it sees fit. The example here
- demonstrates only the logical process and does not dictate any
- implementation rules.
-
- We assume the resolver starts with a configured DNSKEY RRset for the
- root zone (or a configured DS RRset for the root zone). The resolver
- checks whether this configured DNSKEY RRset is present in the root
- DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
- RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
- root DNSKEY RRset, and whether the signature lifetime is valid. If
- all these conditions are met, all keys in the DNSKEY RRset are
- considered authenticated. The resolver then uses one (or more) of
- the root DNSKEY RRs to authenticate the "example" DS RRset. Note
- that the resolver may have to query the root zone to obtain the root
- DNSKEY RRset or "example" DS RRset.
-
- Once the DS RRset has been authenticated using the root DNSKEY, the
- resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
- RR that matches one of the authenticated "example" DS RRs. If such a
- matching "example" DNSKEY is found, the resolver checks whether this
- DNSKEY RR has signed the "example" DNSKEY RRset and the signature
- lifetime is valid. If these conditions are met, all keys in the
- "example" DNSKEY RRset are considered authenticated.
-
- Finally, the resolver checks that some DNSKEY RR in the "example"
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 25]
-\f
-Internet-Draft nsec3 june 2005
-
-
- DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
- DNSKEY is used to authenticate the RRSIG included in the response.
- If multiple "example" DNSKEY RRs match this algorithm and key tag,
- then each DNSKEY RR is tried, and the answer is authenticated if any
- of the matching DNSKEY RRs validate the signature as described above.
-
-B.2 Name Error
-
- An authoritative name error. The NSEC3 RRs prove that the name does
- not exist and that no covering wildcard exists.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 26]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=3
- ;;
- ;; Question
- a.c.x.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
- MX NSEC3 RRSIG )
- 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
- ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
- MEFQmc/gEuxojA== )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- vhgwr2qgykdkf4m6iv6vkagbxozphazr
- HINFO A AAAA NSEC3 RRSIG )
- nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
- z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
- jL33Wm1p07TBdw== )
- ;; Additional
- ;; (empty)
-
- The query returned two NSEC3 RRs that prove that the requested data
- does not exist and no wildcard applies. The negative reply is
- authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are
- authenticated in a manner identical to that of the MX RRset discussed
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 27]
-\f
-Internet-Draft nsec3 june 2005
-
-
- above. At least one of the owner names of the NSEC3 RRs will match
- the closest encloser. At least one of the NSEC3 RRs prove that there
- exists no longer name. At least one of the NSEC3 RRs prove that
- there exists no wildcard RRsets that should have been expanded. The
- closest encloser can be found by hasing the apex ownername (The SOA
- RR's ownername, or the ownername of the DNSKEY RRset referred by an
- RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
- if that fails, continue by adding labels.
-
- In the above example, the name 'x.w.example' hashes to
- '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might
- be the closest encloser. To prove that 'c.x.w.example' and
- '*.x.w.example' do not exists, these names are hashed to respectively
- 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
- 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that
- these hashed ownernames do not exists, since the names are within the
- given intervals.
-
-B.3 No Data Error
-
- A "no data" response. The NSEC3 RR proves that the name exists and
- that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 28]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- ns1.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
- A NSEC3 RRSIG )
- wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
- ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
- oorBv4xkb0flXw== )
- ;; Additional
- ;; (empty)
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
- but the requested RR type does not exist (type MX is absent in the
- type code list of the NSEC RR). The negative reply is authenticated
- by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
- identical to that of the MX RRset discussed above.
-
-B.3.1 No Data Error, Empty Non-Terminal
-
- A "no data" response because of an empty non-terminal. The NSEC3 RR
- proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 29]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example. IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- kcll7fqfnisuhfekckeeqnmbbd4maanu
- NSEC3 RRSIG )
- jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
- IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
- 94Zbq3k8lgdpZA== )
-
- The query returned an NSEC3 RR that proves that the requested name
- exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
- but the requested RR type does not exist (Type A is absent in the
- type-bit-maps of the NSEC3 RR). The negative reply is authenticated
- by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
- identical to that of the MX RRset discussed above. Note that, unlike
- generic empty non terminal proof using NSECs, this is identical to
- proving a No Data Error. This example is solely mentioned to be
- complete.
-
-B.4 Referral to Signed Zone
-
- Referral to a signed zone. The DS RR contains the data which the
- resolver will need to validate the corresponding DNSKEY RR in the
- child zone's apex.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 30]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR DO RCODE=0
- ;;
-
- ;; Question
- mc.a.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- a.example. 3600 IN NS ns1.a.example.
- a.example. 3600 IN NS ns2.a.example.
- a.example. 3600 IN DS 58470 5 1 (
- 3079F1593EBAD6DC121E202A8B766A6A4837
- 206C )
- a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
- cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
- 0kx7rGKTc3RQDA== )
-
- ;; Additional
- ns1.a.example. 3600 IN A 192.0.2.5
- ns2.a.example. 3600 IN A 192.0.2.6
-
- The query returned a referral to the signed "a.example." zone. The
- DS RR is authenticated in a manner identical to that of the MX RRset
- discussed above. This DS RR is used to authenticate the "a.example"
- DNSKEY RRset.
-
- Once the "a.example" DS RRset has been authenticated using the
- "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
- for some "a.example" DNSKEY RR that matches the DS RR. If such a
- matching "a.example" DNSKEY is found, the resolver checks whether
- this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
- the signature lifetime is valid. If all these conditions are met,
- all keys in the "a.example" DNSKEY RRset are considered
- authenticated.
-
-B.5 Referral to Unsigned Zone using Opt-In
-
- Referral to an unsigned zone using Opt-In. The NSEC3 RR proves that
- nothing for this delegation was signed in the parent zone. There is
- no proof that the delegation exists
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 31]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR DO RCODE=0
- ;;
- ;; Question
- mc.b.example. IN MX
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- b.example. 3600 IN NS ns1.b.example.
- b.example. 3600 IN NS ns2.b.example.
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
- deadbeaf
- n42hbhnjj333xdxeybycax5ufvntux5d
- MX NSEC3 RRSIG )
- kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
- IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
- TOLtc5jPrkL4zQ== )
-
- ;; Additional
- ns1.b.example. 3600 IN A 192.0.2.7
- ns2.b.example. 3600 IN A 192.0.2.8
-
- The query returned a referral to the unsigned "b.example." zone. The
- NSEC3 proves that no authentication leads from "example" to
- "b.example", since the hash of "b.example"
- ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
- the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a
- manner identical to that of the MX RRset discussed above.
-
-B.6 Wildcard Expansion
-
- A successful query that was answered via wildcard expansion. The
- label count in the answer's RRSIG RR indicates that a wildcard RRset
- was expanded to produce this response, and the NSEC3 RR proves that
- no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 32]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN MX
-
- ;; Answer
- a.z.w.example. 3600 IN MX 1 ai.example.
- a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
- 20050612112304 62699 example.
- sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
- xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
- gQlgxEwhvQDEaQ== )
- ;; Authority
- example. 3600 NS ns1.example.
- example. 3600 NS ns2.example.
- example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
- m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
- 1SH5r/wfjuCg+g== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
- ;; Additional
- ai.example. 3600 IN A 192.0.2.9
- ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
- 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
- ZXW5S+1VjMZYzQ== )
- ai.example. 3600 AAAA 2001:db8::f00:baa9
- ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
- 20050612112304 62699 example.
- PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
- ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
- l5/UqLCJJ9BDMg== )
-
- The query returned an answer that was produced as a result of
- wildcard expansion. The answer section contains a wildcard RRset
- expanded as it would be in a traditional DNS response, and the
- corresponding RRSIG indicates that the expanded wildcard MX RRset was
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 33]
-\f
-Internet-Draft nsec3 june 2005
-
-
- signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
- The RRSIG indicates that the original TTL of the MX RRset was 3600,
- and, for the purpose of authentication, the current TTL is replaced
- by 3600. The RRSIG labels field value of 2 indicates that the answer
- is the result of wildcard expansion, as the "a.z.w.example" name
- contains 4 labels. The name "a.z.w.example" is replaced by
- "*.w.example", the MX RRset is placed in canonical form, and,
- assuming that the current time falls between the signature inception
- and expiration dates, the signature is authenticated.
-
- The NSEC3 proves that no closer match (exact or closer wildcard)
- could have been used to answer this query, and the NSEC3 RR must also
- be authenticated before the answer is considered valid.
-
-B.7 Wildcard No Data Error
-
- A "no data" response for a name covered by a wildcard. The NSEC3 RRs
- prove that the matching wildcard name does not have any RRs of the
- requested type and that no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 34]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- a.z.w.example. IN AAAA
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
- MX NSEC3 RRSIG )
- zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
- 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
- OcFlrPGPMm48/A== )
- ;; Additional
- ;; (empty)
-
- The query returned NSEC3 RRs that prove that the requested data does
- not exist and no wildcard applies. The negative reply is
- authenticated by verifying both NSEC3 RRs.
-
-B.8 DS Child Zone No Data Error
-
- A "no data" response for a QTYPE=DS query that was mistakenly sent to
- a name server for the child zone.
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 35]
-\f
-Internet-Draft nsec3 june 2005
-
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- example. IN DS
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example. 3600 IN SOA ns1.example. bugs.x.w.example. (
- 1
- 3600
- 300
- 3600000
- 3600
- )
- example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
- 20050612112304 62699 example.
- RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
- mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
- qYIt90txzE/4+g== )
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
- deadbeaf
- gmnfcccja7wkax3iv26bs75myptje3qk
- MX DNSKEY NS SOA NSEC3 RRSIG )
- dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
- 5 2 3600 20050712112304
- 20050612112304 62699 example.
- VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
- C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
- MOiKMSHozVebqw== )
-
- ;; Additional
- ;; (empty)
-
- The query returned NSEC RRs that shows the requested was answered by
- a child server ("example" server). The NSEC RR indicates the
- presence of an SOA RR, showing that the answer is from the child .
- Queries for the "example" DS RRset should be sent to the parent
- servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 36]
-\f
-Internet-Draft nsec3 june 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Laurie, et al. Expires December 3, 2005 [Page 37]
-\f
+++ /dev/null
-
-
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Expires: February 16, 2006 August 15, 2005
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-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 February 16, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document describes a means for automated, authenticated and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against single key compromise of a key 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.
-
- This mechanism, if adopted, will require changes to resolver
- management behavior (but not resolver resolution behavior), and the
-
-
-
-StJohns Expires February 16, 2006 [Page 1]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
- addition of a single flag bit to the DNSKEY record.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
- 1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
- 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 4
- 2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
- 2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
- 2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
- 2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
- 2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
- 2.5.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 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
- 5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
- 5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
- 5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
- 5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
- 6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
- 6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 2]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC2535] [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].
-
-1.2 Changes since -00
-
- Added the concept of timer triggered resolver queries to refresh the
-
-
-
-StJohns Expires February 16, 2006 [Page 3]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
- resolvers view of the trust anchor key RRSet.
-
- Re-submitted expired draft as -01. Updated DNSSEC RFC References.
-
-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 new SEP key is added to a trust point
- DNSKEY RRSet, and when that RRSet is validated by an existing trust
- anchor, then the new key can be added to the set of trust anchors.
-
- 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, an attacker could add a new key and revoke 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 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 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.
-
- 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. [msj3]
-
- In the given example, the attacker could revoke B because it has
- knowledge of B's private key, but could not revoke A.
-
-2.2 Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
-
-
-
-StJohns Expires February 16, 2006 [Page 4]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
- 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 the 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 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 Remove Hold-down
-
- A new key which has been seen by the resolver, but hasn't reached
- it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
- zone owner. If the resolver sees a validated DNSKEY RRSet without
- this key, it waits for the remove hold-down time and then, if the key
- hasn't reappeared, SHOULD discard any information about the key.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 5]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
-2.4 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
- RRSet or half the RRSIG expiration interval. 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.
-
-2.5 Resolver Parameters
-
-2.5.1 Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the TTL
- of the first trust point DNSKEY RRSet which contained the 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.5.2 Remove Hold-Down Time
-
- The remove hold-down time is 30 days.
-
-2.5.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
- validing 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
- 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'.
-
-
-
-StJohns Expires February 16, 2006 [Page 6]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
- The resolver's view of the state of the key changes as various events
- occur.
-
- [msj1] 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 | | | | | | |
- ----------------------------------------------------------
-
-
-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 its 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.
-
-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 hasn't yet been
- seen at the resolver.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 7]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
- 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. [Discussion
- item: Should a missing key be considered revoked after some
- period of time?]
- 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.
-
-5. Scenarios
-
- 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.
-
-5.1 Adding A Trust Anchor
-
- Assume an existing trust anchor key 'A'.
- 1. Generate a new key pair.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 8]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
- 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.
-
-5.2 Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
- 1. Set the revolcation 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.
-
-5.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.
-
-5.4 Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 5.3)
- above assuming 'A' is the active key.
-
-5.5 Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 5.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.
-
-
-
-StJohns Expires February 16, 2006 [Page 9]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
-6. Security Considerations
-
-6.1 Key Ownership vs Acceptance Policy
-
- The reader should note that, while the zone owner is responsible
- 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
- 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.
-
-6.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.
-
-6.3 Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based 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
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-7. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
-
-
-StJohns Expires February 16, 2006 [Page 10]
-\f
-Internet-Draft trustanchor-update August 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
-
- [msj1] msj: N.B. This table is preliminary and will be revised to
- match implementation experience. For example, should there
- be a state for "Add hold-down expired, but haven't seen the
- new RRSet"?
-
- [msj2] msj: To be assigned.
-
- [msj3] msj: For discussion: What's the implementation guidance for
- resolvers currently with respect to the non-assigned flag
- bits? If they consider the flag bit when doing key matching
- at the trust anchor, they won't be able to match.
-
-
-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 February 16, 2006 [Page 11]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
- The IETF has been notified of intellectual property rights claimed in
- regard to some or all of the specification contained in this
- document. For more information consult the online list of claimed
- rights.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 12]
-\f
-Internet-Draft trustanchor-update August 2005
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires February 16, 2006 [Page 13]
-\f
-
+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-UPDATES RFC 2845 Motorola Laboratories
-Expires: December 2005 June 2005
-
-
- HMAC SHA TSIG Algorithm Identifiers
- ---- --- ---- --------- -----------
- <draft-ietf-dnsext-tsig-sha-04.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.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT 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 a "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
-
- Use of the TSIG DNS resource record requires specification of a
- cryptographic message authentication code. Currently identifiers
- have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
- This document standardizes identifiers and implementation
- requirements for additional HMAC SHA TSIG algorithms and standardizes
- how to specify and handle the truncation of HMAC values.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
-
- 2. Algorithms and Identifiers..............................4
-
- 3. Specifying Truncation...................................5
- 3.1 Truncation Specification...............................5
-
- 4. TSIG Policy Provisions and Truncation Error.............7
-
- 5. IANA Considerations.....................................8
- 6. Security Considerations.................................8
- 6. Copyright and Disclaimer................................8
-
- 7. Normative References....................................9
- 8. Informative References..................................9
-
- Author's Address..........................................10
- Expiration and File Name..................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-1. Introduction
-
- [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS queries and responses. This RR contains a domain
- name syntax data item which names the authentication algorithm used.
- [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for
- authentication codes using the HMAC [RFC 2104] algorithm with the MD5
- [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an
- identifier for TSIG authentication where the cryptographic operations
- are delegated to GSS [RFC 3645].
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA algorithms and HMAC
- and specifies the implementation requirements for those algorithms.
-
- In Section 3, this document specifies the meaning of inequality
- between the normal output size of the specified hash function and the
- length of MAC (message authentication code) data given in the TSIG
- RR. In particular, it specifies that a shorter length field value
- specifies truncation and a longer length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation and a new error code to indicate truncation shorter than
- permitted by policy are described and specified.
-
- The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
- defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric signatures
- can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
- can be used for transaction signatures.) Used with a strong hash
- function, HMAC [RFC 2104] provides a way to calculate such symmetric
- authentication codes. The only specified HMAC based TSIG algorithm
- identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
-
- The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
- compared with the 128 bits for MD5, and additional hash algorithms in
- the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
- and 512 bits, may be preferred in some cases particularly since
- increasingly successful cryptanalytic attacks are being made on the
- shorter hashes. Use of TSIG between a DNS resolver and server is by
- mutual agreement. That agreement can include the support of
- additional algorithms and may specify policies as to which algorithms
- and truncations are acceptable subject to the restrication and
- guidelines in Section 3 and 4 below.
-
- The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
- table below for convenience. Implementations which support TSIG MUST
- also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig
- and the other algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols including
- IPSEC and TLS.
-
- The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. But [RFC 2845] does not specify what
- to do if this MAC size differs from the length of the output of HMAC
- for a particular hash function. Truncation is indicated by a MAC size
- less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
- This case MUST NOT be generated and if received MUST cause the
- packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
- Operation is as described in [RFC 2845] with the entire output
- HMAC output present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4 below:
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only be
- to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values compared for
- authentication. The request MAC used when calculating the TSIG MAC
- for a reply is the trucated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
- With the exception of certain TSIG error messages described in
- RFC 2845 section 3.2 where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and if received MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
- size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Policy Provisions and Truncation Error
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are policies as to acceptable keys and
- algorithms and, with the extensions in this doucment, truncations. In
- particular note the following:
-
- Such policies MAY require the rejection of TSIGs even though they
- use an algorithm for which implementation is mandatory.
-
- When a policy calls for the acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of trunction it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- policy, a reply SHOULD be sent with a MAC at least as long as that in
- the corresponding request unless the request specified a MAC length
- longer than the HMAC output.
-
- Implementations permitting policies with multiple acceptable
- algorithms and/or truncations SHOULD permit this list to be ordered
- by presumed strength and SHOULD allow different truncations for the
- same algorithm to be treatred as spearate entities in this list. When
- so implemented, policies SHOULD accept a presumed stronger algorithm
- and truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation which is permitted under
- Section 3 above but the MAC is too short for the policy in force, an
- RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
- This document, on approval for publication as a standards track RFC,
- (1) registers the new TSIG algorithm identifiers listed in Section 2
- with IANA and (2) Section 4 allocates the BADTRUNC RCODE TBA [22
- suggested].
-
-
-
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to brute force
- [RFC 2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the type used herein, all of which ultimately derive from
- the design of MD4. While the results so far should not effect HMAC,
- the stronger SHA-1 and SHA-256 algorithms are being made mandatory
- due to caution.
-
- See the Security Considerations section of [RFC 2845]. See also the
- Security Considerations section of [RFC 2104] from which the limits
- on truncation in this RFC were taken.
-
-
-
-6. Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
- 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.
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-7. Normative References
-
- [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
- Federal Information Processing Standard, with Change Notice 1,
- February 2004.
-
- [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
- 1321, April 1992.
-
- [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February 1997.
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
-
-
-8. Informative References.
-
- [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
- Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead,
- J., and R. Hall, "Generic Security Service Algorithm for Secret Key
- Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
- 2003.
-
- [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
- September 2004,
-
- [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
- (SHA)", work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 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 December 2005.
-
- Its file name is draft-ietf-dnsext-tsig-sha-04.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-DNSEXT Working Group E. Lewis
-INTERNET DRAFT NeuStar
-Expiration Date: January 6, 2006 July 6, 2005
-Updates RFC 1034, RFC 2672
-
- The Role of Wildcards
- in the Domain Name System
- draft-ietf-dnsext-wcard-clarify-08.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 January 6, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This is an update to the wildcard definition of RFC 1034. The
- interaction with wildcards and CNAME is changed, an error
- condition removed, and the words defining some concepts central
- to wildcards are changed. The overall goal is not to change
- wildcards, but to refine the definition of RFC 1034.
-
-Table of Contents
-
-1. Introduction
-1.1 Motivation
-1.2 The Original Definition
-1.3 Roadmap to This Document
-1.3.1 New Terms
-1.3.2 Changed Text
-1.3.3 Considerations with Special Types
-1.4 Standards Terminology
-2. Wildcard Syntax
-2.1 Identifying a Wildcard
-2.1.1 Wild Card Domain Name and Asterisk Label
-2.1.2 Asterisks and Other Characters
-2.1.3 Non-terminal Wild Card Domain Names
-2.2 Existence Rules
-2.2.1 An Example
-2.2.2 Empty Non-terminals
-2.2.3 Yet Another Definition of Existence
-2.3 When is a Wild Card Domain Name Not Special
-3. Impact of a Wild Card Domain Name On a Response
-3.1 Step 2
-3.2 Step 3
-3.3 Part 'c'
-3.3.1 Closest Encloser and the Source of Synthesis
-3.3.2 Closest Encloser and Source of Synthesis Examples
-3.3.3 Type Matching
-4. Considerations with Special Types
-4.1 SOA RRSet at a Wild Card Domain Name
-4.2 NS RRSet at a Wild Card Domain Name
-4.2.1 Discarded Notions
-4.3 CNAME RRSet at a Wild Card Domain Name
-4.4 DNAME RRSet at a Wild Card Domain Name
-4.5 SRV RRSet at a Wild Card Domain Name
-4.6 DS RRSet at a Wild Card Domain Name
-4.7 NSEC RRSet at a Wild Card Domain Name
-4.8 RRSIG at a Wild Card Domain Name
-4.9 Empty Non-terminal Wild Card Domain Name
-5. Security Considerations
-6. IANA Considerations
-7. References
-8. Editor
-9. Others Contributing to the Document
-10. Trailing Boilerplate
-
-1. Introduction
-
- In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
- synthesis of answers from special resource records called
- wildcards. The definition in RFC 1034 is incomplete and has
- proven to be confusing. This document describes the wildcard
- synthesis by adding to the discussion and making limited
- modifications. Modifications are made to close inconsistencies
- that have led to interoperability issues. This description
- does not expand the service intended by the original definition.
-
- Staying within the spirit and style of the original documents,
- this document avoids specifying rules for DNS implementations
- regarding wildcards. The intention is to only describe what is
- needed for interoperability, not restrict implementation choices.
- In addition, consideration is given to minimize any backwards
- compatibility issues with implementations that comply with RFC
- 1034's definition.
-
- This document is focused on the concept of wildcards as defined
- in RFC 1034. Nothing is implied regarding alternative means of
- synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
- Many DNS implementations diverge, in different ways, from the
- original definition of wildcards. Although there is clearly a
- need to clarify the original documents in light of this alone,
- the impetus for this document lay in the engineering of the DNS
- security extensions [RFC4033]. With an unclear definition of
- wildcards the design of authenticated denial became entangled.
-
- This document is intended to limit its changes, documenting only
- those based on implementation experience, and to remain as close
- to the original document as possible. To reinforce that this
- document is meant to clarify and adjust and not redefine wildcards,
- relevant sections of RFC 1034 are repeated verbatim to facilitate
- comparison of the old and new text.
-
-1.2 The Original Definition
-
- The defintion of the wildcard concept is comprised by the
- documentation of the algorithm by which a name server prepares
- a response (in RFC 1034's section 4.3.2) and the way in which
- a resource record (set) is identified as being a source of
- synthetic data (section 4.3.3).
-
- This is the definition of the term "wildcard" as it appears in
- RFC 1034, section 4.3.3.
-
-# In the previous algorithm, special treatment was given to RRs with
-# owner names starting with the label "*". Such RRs are called
-# wildcards. Wildcard RRs can be thought of as instructions for
-# synthesizing RRs. When the appropriate conditions are met, the name
-# server creates RRs with an owner name equal to the query name and
-# contents taken from the wildcard RRs.
-
- This passage follows the algorithm in which the term wildcard
- is first used. In this definition, wildcard refers to resource
- records. In other usage, wildcard has referred to domain names,
- and it has been used to describe the operational practice of
- relying on wildcards to generate answers. It is clear from this
- that there is a need to define clear and unambiguous terminology
- in the process of discussing wildcards.
-
- The mention of the use of wildcards in the preparation of a
- response is contained in step 3c of RFC 1034's section 4.3.2
- entitled "Algorithm." Note that "wildcard" does not appear in
- the algorithm, instead references are made to the "*" label.
- The portion of the algorithm relating to wildcards is
- deconstructed in detail in section 3 of this document, this is
- the beginning of the relevant portion of the "Algorithm."
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# the "*" label exists.
-
- The scope of this document is the RFC 1034 definition of
- wildcards and the implications of updates to those documents,
- such as DNSSEC. Alternate schemes for synthesizing answers are
- not considered. (Note that there is no reference listed. No
- document is known to describe any alternate schemes, although
- there has been some mention of them in mailing lists.)
-
-1.3 Roadmap to This Document
-
- This document accomplishes these three items.
- o Defines new terms
- o Makes minor changes to avoid conflicting concepts
- o Describes the actions of certain resource records as wildcards
-
-1.3.1 New Terms
-
- To help in discussing what resource records are wildcards, two
- terms will be defined - "asterisk label" and "wild card domain
- name". These are defined in section 2.1.1.
-
- To assist in clarifying the role of wildcards in the name server
- algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
- encloser" are defined. These definitions are in section 3.3.2.
- "Label match" is defined in section 3.2.
-
- The new terms are used to make discussions of wildcards clearer.
- Terminology doesn't directly have an impact on implementations.
-
-1.3.2 Changed Text
-
- The definition of "existence" is changed superficially. This
- change will not be apparent to implementations; it is needed to
- make descriptions more precise. The change appears in section
- 2.2.3.
-
- RFC 1034, section 4.3.3., seems to prohibit having two asterisk
- labels in a wildcard owner name. With this document the
- restriction is removed entirely. This change and its implications
- are in section 2.1.3.
-
- The actions when a source of synthesis owns a CNAME RR are
- changed to mirror the actions if an exact match name owns a
- CNAME RR. This is an addition to the words in RFC 1034,
- section 4.3.2, step 3, part c. The discussion of this is in
- section 3.3.3.
-
- Only the latter change represents an impact to implementations.
- The definition of existence is not a protocol impact. The change
- to the restriction on names is unlikely to have an impact, as
- RFC 1034 contained no specification on when and how to enforce the
- restriction.
-
-1.3.3 Considerations with Special Types
-
- This document describes semantics of wildcard RRSets for
- "interesting" types as well as empty non-terminal wildcards.
- Understanding these situations in the context of wildcards has
- been clouded because these types incur special processing if
- they are the result of an exact match. This discussion is in
- section 4.
-
- These discussions do not have an implementation impact, they cover
- existing knowledge of the types, but to a greater level of detail.
-
-1.4 Standards Terminology
-
- This document does not use terms as defined in "Key words for use
- in RFCs to Indicate Requirement Levels." [RFC2119]
-
- Quotations of RFC 1034 are denoted by a '#' in the leftmost
- column. References to section "4.3.2" are assumed to refer
- to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-2. Wildcard Syntax
-
- The syntax of a wildcard is the same as any other DNS resource
- record, across all classes and types. The only significant
- feature is the owner name.
-
- Because wildcards are encoded as resource records with special
- names, they are included in zone transfers and incremental zone
- transfers[RFC1995] just as non-wildcard resource records are.
- This feature has been underappreciated until discussions on
- alternative approaches to wildcards appeared on mailing lists.
-
-2.1 Identifying a Wildcard
-
- To provide a more accurate description of wildcards, the
- definition has to start with a discussion of the domain names
- that appear as owners. Two new terms are needed, "Asterisk
- Label" and "Wild Card Domain Name."
-
-2.1.1 Wild Card Domain Name and Asterisk Label
-
- A "wild card domain name" is defined by having its initial
- (i.e., left-most or least significant) label be, in binary format:
-
- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
- The first octet is the normal label type and length for a 1 octet
- long label, the second octet is the ASCII representation [RFC20]
- for the '*' character.
-
- A descriptive name of a label equaling that value is an "asterisk
- label."
-
- RFC 1034's definition of wildcard would be "a resource record
- owned by a wild card domain name."
-
-2.1.2 Asterisks and Other Characters
-
- No label values other than that in section 2.1.1 are asterisk
- labels, hence names beginning with other labels are never wild
- card domain names. Labels such as 'the*' and '**' are not
- asterisk labels so these labels do not start wild card domain
- names.
-
-2.1.3 Non-terminal Wild Card Domain Names
-
- In section 4.3.3, the following is stated:
-
-# .......................... The owner name of the wildcard RRs is of
-# the form "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
- The restriction is now removed. The original documentation of it
- is incomplete and the restriction does not serve any purpose given
- years of operational experience.
-
- There are three possible reasons for putting the restriction in
- place, but none of the three has held up over time. One is
- that the restriction meant that there would never be subdomains
- of wild card domain names, but the restriciton as stated still
- permits "example.*.example." for instance. Another is that
- wild card domain names are not intended to be empty non-terminals,
- but this situation does not disrupt the algorithm in 4.3.2.
- Finally, "nested" wild card domain names are not ambiguous once
- the concept of the closest encloser had been documented.
-
- A wild card domain name can have subdomains. There is no need
- to inspect the subdomains to see if there is another asterisk
- label in any subdomain.
-
- A wild card domain name can be an empty non-terminal. (See the
- upcoming sections on empty non-terminals.) In this case, any
- lookup encountering it will terminate as would any empty
- non-terminal match.
-
-2.2 Existence Rules
-
- The notion that a domain name 'exists' is mentioned in the
- definition of wildcards. In section 4.3.3 of RFC 1034:
-
-# Wildcard RRs do not apply:
-#
-...
-# - When the query name or a name between the wildcard domain and
-# the query name is know[n] to exist. For example, if a wildcard
-
- "Existence" is therefore an important concept in the understanding
- of wildcards. Unfortunately, the definition of what exists, in RFC
- 1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is
- taken at the definition of existence.
-
-2.2.1 An Example
-
- To illustrate what is meant by existence consider this complete
- zone:
-
- $ORIGIN example.
- example. 3600 IN SOA <SOA RDATA>
- example. 3600 NS ns.example.com.
- example. 3600 NS ns.example.net.
- *.example. 3600 TXT "this is a wild card"
- *.example. 3600 MX 10 host1.example.
- sub.*.example. 3600 TXT "this is not a wild card"
- host1.example. 3600 A 192.0.4.1
- _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
- _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
- subdel.example. 3600 NS ns.example.com.
- subdel.example. 3600 NS ns.example.net.
-
- A look at the domain names in a tree structure is helpful:
-
- |
- -------------example------------
- / / \ \
- / / \ \
- / / \ \
- * host1 host2 subdel
- | | |
- | | |
- sub _tcp _tcp
- | |
- | |
- _ssh _ssh
-
- The following responses would be synthesized from one of the
- wildcards in the zone:
-
- QNAME=host3.example. QTYPE=MX, QCLASS=IN
- the answer will be a "host3.example. IN MX ..."
-
- QNAME=host3.example. QTYPE=A, QCLASS=IN
- the answer will reflect "no error, but no data"
- because there is no A RR set at '*.example.'
-
- QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
- the answer will be "foo.bar.example. IN TXT ..."
- because bar.example. does not exist, but the wildcard
- does.
-
- The following responses would not be synthesized from any of the
- wildcards in the zone:
-
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
-
- QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
- because sub.*.example. exists
-
- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
- because _tcp.host1.example. exists (without data)
-
- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
- because subdel.example. exists (and is a zone cut)
-
- QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
- because *.example. exists
-
- The final example highlights one common misconception about
- wildcards. A wildcard "blocks itself" in the sense that a
- wildcard does not match its own subdomains. I.e. "*.example."
- does not match all names in the "example." zone, it fails to
- match the names below "*.example." To cover names under
- "*.example.", another wild card domain name is needed -
- "*.*.example." - which covers all but it's own subdomains.
-
-2.2.2 Empty Non-terminals
-
- Empty non-terminals [RFC2136, Section 7.16] are domain names
- that own no resource records but have subdomains that do. In
- section 2.2.1, "_tcp.host1.example." is an example of a empty
- non-terminal name. Empty non-terminals are introduced by this
- text in section 3.1 of RFC 1034:
-
-# The domain name space is a tree structure. Each node and leaf on
-# the tree corresponds to a resource set (which may be empty). The
-# domain system makes no distinctions between the uses of the
-# interior nodes and leaves, and this memo uses the term "node" to
-# refer to both.
-
- The parenthesized "which may be empty" specifies that empty non-
- terminals are explicitly recognized, and that empty non-terminals
- "exist."
-
- Pedantically reading the above paragraph can lead to an
- interpretation that all possible domains exist - up to the
- suggested limit of 255 octets for a domain name [RFC1035].
- For example, www.example. may have an A RR, and as far as is
- practically concerned, is a leaf of the domain tree. But the
- definition can be taken to mean that sub.www.example. also
- exists, albeit with no data. By extension, all possible domains
- exist, from the root on down.
-
- As RFC 1034 also defines "an authoritative name error indicating
- that the name does not exist" in section 4.3.1, so this apparently
- is not the intent of the original definition, justifying the
- need for an updated definition in the next section.
-
-2.2.3 Yet Another Definition of Existence
-
- RFC1034's wording is fixed by the following paragraph:
-
- The domain name space is a tree structure. Nodes in the tree
- either own at least one RRSet and/or have descendants that
- collectively own at least one RRSet. A node may exist with no
- RRSets only if it has descendents that do, this node is an empty
- non-terminal.
-
- A node with no descendants is a leaf node. Empty leaf nodes do
- not exist.
-
- Note that at a zone boundary, the domain name owns data,
- including the NS RR set. In the delegating zone, the NS RR
- set is not authoritative, but that is of no consequence here.
- The domain name owns data, therefore, it exists.
-
-2.3 When is a Wild Card Domain Name Not Special
-
- When a wild card domain name appears in a message's query section,
- no special processing occurs. An asterisk label in a query name
- only matches a single, corresponding asterisk label in the
- existing zone tree when the 4.3.2 algorithm is being followed.
-
- When a wild card domain name appears in the resource data of a
- record, no special processing occurs. An asterisk label in that
- context literally means just an asterisk.
-
-3. Impact of a Wild Card Domain Name On a Response
-
- RFC 1034's description of how wildcards impact response
- generation is in its section 4.3.2. That passage contains the
- algorithm followed by a server in constructing a response.
- Within that algorithm, step 3, part 'c' defines the behavior of
- the wildcard.
-
- The algorithm in section 4.3.2. is not intended to be pseudo-code,
- i.e., its steps are not intended to be followed in strict order.
- The "algorithm" is a suggested means of implementing the
- requirements. As such, in step 3, parts a, b, and c, do not have
- to be implemented in that order, provided that the result of the
- implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
- Step 2 of the section 4.3.2 reads:
-
-# 2. Search the available zones for the zone which is the nearest
-# ancestor to QNAME. If such a zone is found, go to step 3,
-# otherwise step 4.
-
- In this step, the most appropriate zone for the response is
- chosen. The significance of this step is that it means all of
- step 3 is being performed within one zone. This has significance
- when considering whether or not an SOA RR can be ever be used for
- synthesis.
-
-3.2 Step 3
-
- Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
- But the beginning of the step is important and needs explanation.
-
-# 3. Start matching down, label by label, in the zone. The
-# matching process can terminate several ways:
-
- The word 'matching' refers to label matching. The concept
- is based in the view of the zone as the tree of existing names.
- The query name is considered to be an ordered sequence of
- labels - as if the name were a path from the root to the owner
- of the desired data. (Which it is - 3rd paragraph of RFC 1034,
- section 3.1.)
-
- The process of label matching a query name ends in exactly one of
- three choices, the parts 'a', 'b', and 'c'. Either the name is
- found, the name is below a cut point, or the name is not found.
-
- Once one of the parts is chosen, the other parts are not
- considered. (E.g., do not execute part 'c' and then change
- the execution path to finish in part 'b'.) The process of label
- matching is also done independent of the query type (QTYPE).
-
- Parts 'a' and 'b' are not an issue for this clarification as they
- do not relate to record synthesis. Part 'a' is an exact match
- that results in an answer, part 'b' is a referral.
-
-3.3 Part 'c'
-
- The context of part 'c' is that the process of label matching the
- labels of the query name has resulted in a situation in which
- there is no corresponding label in the tree. It is as if the
- lookup has "fallen off the tree."
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if [...]
-# the "*" label exists.
-
- To help describe the process of looking 'to see if [...] the "*"
- label exists' a term has been coined to describe the last domain
- (node) matched. The term is "closest encloser."
-
-3.3.1 Closest Encloser and the Source of Synthesis
-
- The closest encloser is the node in the zone's tree of existing
- domain names that has the most labels matching the query name
- (consecutively, counting from the root label downward). Each match
- is a "label match" and the order of the labels is the same.
-
- The closest encloser is, by definition, an existing name in the
- zone. The closest encloser might be an empty non-terminal or even
- be a wild card domain name itself. In no circumstances is the
- closest encloser to be used to synthesize records for the current
- query.
-
- The source of synthesis is defined in the context of a query
- process as that wild card domain name immediately descending
- from the closest encloser, provided that this wild card domain
- name exists. "Immediately descending" means that the source
- of synthesis has a name of the form:
- <asterisk label>.<closest encloser>.
- A source of synthesis does not guarantee having a RRSet to use
- for synthesis. The source of synthesis could be an empty
- non-terminal.
-
- If the source of synthesis does not exist (not on the domain
- tree), there will be no wildcard synthesis. There is no search
- for an alternate.
-
- The important concept is that for any given lookup process, there
- is at most one place at which wildcard synthetic records can be
- obtained. If the source of synthesis does not exist, the lookup
- terminates, the lookup does not look for other wildcard records.
-
-3.3.2 Closest Encloser and Source of Synthesis Examples
-
- To illustrate, using the example zone in section 2.2.1 of this
- document, the following chart shows QNAMEs and the closest
- enclosers.
-
- QNAME Closest Encloser Source of Synthesis
- host3.example. example. *.example.
- _telnet._tcp.host1.example. _tcp.host1.example. no source
- _telnet._tcp.host2.example. host2.example. no source
- _telnet._tcp.host3.example. example. *.example.
- _chat._udp.host3.example. example. *.example.
- foobar.*.example. *.example. no source
-
-3.3.3 Type Matching
-
- RFC 1034 concludes part 'c' with this:
-
-# If the "*" label does not exist, check whether the name
-# we are looking for is the original QNAME in the query
-# or a name we have followed due to a CNAME. If the name
-# is original, set an authoritative name error in the
-# response and exit. Otherwise just exit.
-#
-# If the "*" label does exist, match RRs at that node
-# against QTYPE. If any match, copy them into the answer
-# section, but set the owner of the RR to be QNAME, and
-# not the node with the "*" label. Go to step 6.
-
- The final paragraph covers the role of the QTYPE in the lookup
- process.
-
- Based on implementation feedback and similarities between step
- 'a' and step 'c' a change to this passage has been made.
-
- The change is to add the following text to step 'c' prior to the
- instructions to "go to step 6":
-
- If the data at the source of synthesis is a CNAME, and
- QTYPE doesn't match CNAME, copy the CNAME RR into the
- answer section of the response changing the owner name
- to the QNAME, change QNAME to the canonical name in the
- CNAME RR, and go back to step 1.
-
- This is essentially the same text in step a covering the
- processing of CNAME RRSets.
-
-4. Considerations with Special Types
-
- Sections 2 and 3 of this document discuss wildcard synthesis
- with respect to names in the domain tree and ignore the impact
- of types. In this section, the implication of wildcards of
- specific types are discussed. The types covered are those
- that have proven to be the most difficult to understand. The
- types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
- "none," i.e., empty non-terminal wild card domain names.
-
-4.1 SOA RRSet at a Wild Card Domain Name
-
- A wild card domain name owning an SOA RRSet means that the
- domain is at the root of the zone (apex). The domain can not
- be a source of synthesis because that is, by definition, a
- descendent node (of the closest encloser) and a zone apex is
- at the top of the zone.
-
- Although a wild card domain name owning an SOA RRSet can never
- be a source of synthesis, there is no reason to forbid the
- ownership of an SOA RRSet.
-
- E.g., given this zone:
- $ORIGIN *.example.
- @ 3600 IN SOA <SOA RDATA>
- 3600 NS ns1.example.com.
- 3600 NS ns1.example.net.
- www 3600 TXT "the www txt record"
-
- A query for www.*.example.'s TXT record would still find the
- "the www txt record" answer. The reason is that the asterisk
- label only becomes significant when section's 4.3.2, step 3
- part 'c' in in effect.
-
- Of course, there would need to be a delegation in the parent
- zone, "example." for this to work too. This is covered in the
- next section.
-
-4.2 NS RRSet at a Wild Card Domain Name
-
- With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
- in place, the semantics of a wild card domain name owning an
- NS RRSet has come to be poorly defined. The dilemma relates to
- a conflict between the rules for synthesis in part 'c' and the
- fact that the resulting synthesis generates a record for which
- the zone is not authoritative. In a DNSSEC signed zone, the
- mechanics of signature management (generation and inclusion
- in a message) become unclear.
-
- After some lengthy discussions, there has been no clear "best
- answer" on how to document the semantics of such a situation.
- Barring such records from the DNS would require definition of
- rules for that, as well as introducing a restriction on records
- that were once legal. Allowing such records and amending the
- process of signature management would entail complicating the
- DNSSEC definition.
-
- There is one more ingredient to the discussion, that being the
- utility of a wild card domain name owned NS RRSet. Although
- there are cases of this use, it is an operational rarity.
- Expending effort to close this topic has proven to be an
- exercise in diminishing returns.
-
- In summary, there is no definition given for wild card domain
- names owning an NS RRSet. The semantics are left undefined until
- there is a clear need to have a set defined, and until there is
- a clear direction to proceed. Operationally, inclusion of wild
- card NS RRSets in a zone is discouraged, but not barred.
-
-4.2.1 Discarded Notions
-
- Prior to DNSSEC, a wild card domain name owning a NS RRSet
- appeared to be workable, and there are some instances in which
- it is found in deployments using implementations that support
- this. Continuing to allow this in the specificaion is not
- tenable with DNSSEC. The reason is that the synthesis of the
- NS RRSet is being done in a zone that has delegated away the
- responsibility for the name. This "unauthorized" synthesis is
- not a problem for the base DNS protocol, but DNSSEC, in affirming
- the authorization model for DNS exposes the problem.
-
- Outright banning of wildcards of type NS is also untenable as
- the DNS protocol does not define how to handle "illegal" data.
- Implementations may choose not to load a zone, but there is no
- protocol definition. The lack of the definition is complicated
- by having to cover dynamic update [RFC 2136], zone transfers,
- as well as loading at the master server. The case of a client
- (resolver, cacheing server) getting a wildcard of type NS in
- a reply would also have to be considered.
-
- Given the daunting challenge of a complete definition of how to
- ban such records, dealing with existing implementations that
- permit the records today is a further complication. There are
- uses of wild card domain name owning NS RRSets.
-
- One compromise proposed would have redefined wildcards of type
- NS to not be used in synthesis, this compromise fell apart
- because it would have required significant edits to the DNSSEC
- signing and validation work. (Again, DNSSEC catches
- unauthorized data.)
-
- With no clear consensus forming on the solution to this dilemma,
- and the realization that wildcards of type NS are a rarity in
- operations, the best course of action is to leave this open-ended
- until "it matters."
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
- The issue of a CNAME RRSet owned by a wild card domain name has
- prompted a suggested change to the last paragraph of step 3c of
- the algorithm in 4.3.2. The changed text appears in section
- 3.3.3 of this document.
-
-4.4 DNAME RRSet at a Wild Card Domain Name
-
- Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
- represents a threat to the coherency of the DNS and is to be
- avoided or outright rejected. Such a DNAME RRSet represents
- non-deterministic synthesis of rules fed to different caches.
- As caches are fed the different rules (in an unpredictable
- manner) the caches will cease to be coherent. ("As caches
- are fed" refers to the storage in a cache of records obtained
- in responses by recursive or iterative servers.)
-
- For example, assume one cache, responding to a recursive
- request, obtains the record:
- "a.b.example. DNAME foo.bar.example.net."
- and another cache obtains:
- "b.example. DNAME foo.bar.example.net."
- both generated from the record:
- "*.example. DNAME foo.bar.example.net."
- by an authoritative server.
-
- The DNAME specification is not clear on whether DNAME records
- in a cache are used to rewrite queries. In some interpretations,
- the rewrite occurs, in some, it is not. Allowing for the
- occurrence of rewriting, queries for "sub.a.b.example. A" may
- be rewritten as "sub.foo.bar.tld. A" by the former caching
- server and may be rewritten as "sub.a.foo.bar.tld. A" by the
- latter. Coherency is lost, an operational nightmare ensues.
-
- Another justification for banning or avoiding wildcard DNAME
- records is the observation that such a record could synthesize
- a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
- There is a restriction in the DNAME definition that no domain
- exist below a DNAME-owning domain, hence, the wildcard DNAME
- is not to be permitted.
-
-4.5 SRV RRSet at a Wild Card Domain Name
-
- The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
- definition of the record, there is some confusion over the term
- "Name." The definition reads as follows:
-
-# The format of the SRV RR
-...
-# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-...
-# Name
-# The domain this RR refers to. The SRV RR is unique in that the
-# name one searches for is not this name; the example near the end
-# shows this clearly.
-
- Do not confuse the definition "Name" with the owner name. I.e.,
- once removing the _Service and _Proto labels from the owner name
- of the SRV RRSet, what remains could be a wild card domain name
- but this is immaterial to the SRV RRSet.
-
- E.g., If an SRV record is:
- _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
-
- *.example is a wild card domain name and although it it the Name
- of the SRV RR, it is not the owner (domain name). The owner
- domain name is "_foo._udp.*.example." which is not a wild card
- domain name.
-
- The confusion is likely based on the mixture of the specification
- of the SRV RR and the description of a "use case."
-
-4.6 DS RRSet at a Wild Card Domain Name
-
- A DS RRSet owned by a wild card domain name is meaningless and
- harmless. This statement is made in the context that an NS RRSet
- at a wild card domain name is undefined. At a non-delegation
- point, a DS RRSet has no value (no corresponding DNSKEY RRSet
- will be used in DNSSEC validation). If there is a synthesized
- DS RRSet, it alone will not be very useful as it exists in the
- context of a delegation point.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
- Wild card domain names in DNSSEC signed zones will have an NSEC
- RRSet. Synthesis of these records will only occur when the
- query exactly matches the record. Synthesized NSEC RR's will not
- be harmful as they will never be used in negative caching or to
- generate a negative response.
-
-4.8 RRSIG at a Wild Card Domain Name
-
- RRSIG records will be present at a wild card domain name in a
- signed zone, and will be synthesized along with data sought in a
- query. The fact that the owner name is synthesized is not a
- problem as the label count in the RRSIG will instruct the
- verifying code to ignore it.
-
-4.9 Empty Non-terminal Wild Card Domain Name
-
- If a source of synthesis is an empty non-terminal, then the
- response will be one of no error in the return code and no RRSet
- in the answer section.
-
-5. Security Considerations
-
- This document is refining the specifications to make it more
- likely that security can be added to DNS. No functional
- additions are being made, just refining what is considered
- proper to allow the DNS, security of the DNS, and extending
- the DNS to be more predictable.
-
-6. IANA Considerations
-
- None.
-
-7. References
-
- Normative References
-
- [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
- Oct-16-1969
-
- [RFC1034] Domain Names - Concepts and Facilities,
- P.V. Mockapetris, Nov-01-1987
-
- [RFC1035] Domain Names - Implementation and Specification, P.V
- Mockapetris, Nov-01-1987
-
- [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
- [RFC2119] Key Words for Use in RFCs to Indicate Requirement
- Levels, S Bradner, March 1997
-
- [RFC2181] Clarifications to the DNS Specification, R. Elz and
- R. Bush, July 1997
-
- [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
- M. Andrews, March 1998
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999.
-
- [RFC2782] A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, et.al., February 2000
-
- [RFC4033] DNS Security Introduction and Requirements, R. Arends,
- et.al., March 2005
-
- [RFC4034] Resource Records for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC4035] Protocol Modifications for the DNS Security Extensions,
- R. Arends, et.al., March 2005
-
- [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
- August 1999
-
- Informative References
-
- [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- April 1997
-
-8. Editor
-
- Name: Edward Lewis
- Affiliation: NeuStar
- Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
- Phone: +1-571-434-5468
- Email: ed.lewis@neustar.biz
-
- Comments on this document can be sent to the editor or the mailing
- list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-9. Others Contributing to the Document
-
- This document represents the work of a large working group. The
- editor merely recorded the collective wisdom of the working group.
-
-10. Trailing Boilerplate
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided
- on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
- HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
- SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
- WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
- ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
- INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of
- any Intellectual Property Rights or other rights that might
- be claimed to pertain to the implementation or use of the
- technology described in this document or the extent to which
- any license under such rights might or might not be available;
- nor does it represent that it has made any independent effort
- to identify any such rights. Information on the procedures
- with respect to rights in RFC documents can be found in BCP 78
- and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the
- use of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR
- repository at http://www.ietf.org/ipr. The IETF invites any
- interested party to bring to its attention any copyrights,
- patents or patent applications, or other proprietary rights
- that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Expiration
-
- This document expires on or about January 6, 2006.
+++ /dev/null
-
-
-
-DNS Operations M. Larson
-Internet-Draft P. Barber
-Expires: January 18, 2006 VeriSign
- July 17, 2005
-
-
- Observed DNS Resolution Misbehavior
- draft-ietf-dnsop-bad-dns-res-04
-
-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 January 18, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This memo describes DNS iterative resolver behavior that results in a
- significant query volume sent to the root and top-level domain (TLD)
- name servers. We offer implementation advice to iterative resolver
- developers to alleviate these unnecessary queries. The
- recommendations made in this document are a direct byproduct of
- observation and analysis of abnormal query traffic patterns seen at
- two of the thirteen root name servers and all thirteen com/net TLD
- name servers.
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 1]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- 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].
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 A note about terminology in this memo . . . . . . . . . . 3
- 2. Observed iterative resolver misbehavior . . . . . . . . . . 5
- 2.1 Aggressive requerying for delegation information . . . . . 5
- 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . 6
- 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 7
- 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . 7
- 2.3 Inability to follow multiple levels of indirection . . . . 8
- 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . 9
- 2.4 Aggressive retransmission when fetching glue . . . . . . . 9
- 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . 10
- 2.5 Aggressive retransmission behind firewalls . . . . . . . . 10
- 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . 11
- 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 11
- 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . 12
- 2.7 Name server records with zero TTL . . . . . . . . . . . . 12
- 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . 13
- 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 13
- 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.9 Queries for domain names resembling IPv4 addresses . . . . 14
- 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . 14
- 2.10 Misdirected recursive queries . . . . . . . . . . . . . 15
- 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . 15
- 2.11 Suboptimal name server selection algorithm . . . . . . . 15
- 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . 16
- 3. IANA considerations . . . . . . . . . . . . . . . . . . . . 17
- 4. Security considerations . . . . . . . . . . . . . . . . . . 18
- 5. Internationalization considerations . . . . . . . . . . . . 19
- 6. Informative References . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
- Intellectual Property and Copyright Statements . . . . . . . 21
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 2]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-1. Introduction
-
- Observation of query traffic received by two root name servers and
- the thirteen com/net TLD name servers has revealed that a large
- proportion of the total traffic often consists of "requeries". A
- requery is the same question (<QNAME, QTYPE, QCLASS>) asked
- repeatedly at an unexpectedly high rate. We have observed requeries
- from both a single IP address and multiple IP addresses (i.e., the
- same query received simultaneously from multiple IP addresses).
-
- By analyzing requery events we have found that the cause of the
- duplicate traffic is almost always a deficient iterative resolver,
- stub resolver or application implementation combined with an
- operational anomaly. The implementation deficiencies we have
- identified to date include well-intentioned recovery attempts gone
- awry, insufficient caching of failures, early abort when multiple
- levels of indirection must be followed, and aggressive retry by stub
- resolvers or applications. Anomalies that we have seen trigger
- requery events include lame delegations, unusual glue records, and
- anything that makes all authoritative name servers for a zone
- unreachable (DoS attacks, crashes, maintenance, routing failures,
- congestion, etc.).
-
- In the following sections, we provide a detailed explanation of the
- observed behavior and recommend changes that will reduce the requery
- rate. None of the changes recommended affects the core DNS protocol
- specification; instead, this document consists of guidelines to
- implementors of iterative resolvers.
-
-1.1 A note about terminology in this memo
-
- To recast an old saying about standards, the nice thing about DNS
- terms is that there are so many of them to choose from. Writing or
- talking about DNS can be difficult and cause confusion resulting from
- a lack of agreed-upon terms for its various components. Further
- complicating matters are implementations that combine multiple roles
- into one piece of software, which makes naming the result
- problematic. An example is the entity that accepts recursive
- queries, issues iterative queries as necessary to resolve the initial
- recursive query, caches responses it receives, and which is also able
- to answer questions about certain zones authoritatively. This entity
- is an iterative resolver combined with an authoritative name server
- and is often called a "recursive name server" or a "caching name
- server".
-
- This memo is concerned principally with the behavior of iterative
- resolvers, which are typically found as part of a recursive name
- server. This memo uses the more precise term "iterative resolver",
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 3]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- because the focus is usually on that component. In instances where
- the name server role of this entity requires mentioning, this memo
- uses the term "recursive name server". As an example of the
- difference, the name server component of a recursive name server
- receives DNS queries and the iterative resolver component sends
- queries.
-
- The advent of IPv6 requires mentioning AAAA records as well as A
- records when discussing glue. To avoid continuous repetition and
- qualification, this memo uses the general term "address record" to
- encompass both A and AAAA records when a particular situation is
- relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 4]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-2. Observed iterative resolver misbehavior
-
-2.1 Aggressive requerying for delegation information
-
- There can be times when every name server in a zone's NS RRset is
- unreachable (e.g., during a network outage), unavailable (e.g., the
- name server process is not running on the server host) or
- misconfigured (e.g., the name server is not authoritative for the
- given zone, also known as "lame"). Consider an iterative resolver
- that attempts to resolve a query for a domain name in such a zone and
- discovers that none of the zone's name servers can provide an answer.
- We have observed a recursive name server implementation whose
- iterative resolver then verifies the zone's NS RRset in its cache by
- querying for the zone's delegation information: it sends a query for
- the zone's NS RRset to one of the parent zone's name servers. (Note
- that queries with QTYPE=NS are not required by the standard
- resolution algorithm described in section 4.3.2 of RFC 1034 [2].
- These NS queries represent this implementation's addition to that
- algorithm.)
-
- For example, suppose that "example.com" has the following NS RRset:
-
- example.com. IN NS ns1.example.com.
- example.com. IN NS ns2.example.com.
-
- Upon receipt of a query for "www.example.com" and assuming that
- neither "ns1.example.com" nor "ns2.example.com" can provide an
- answer, this iterative resolver implementation immediately queries a
- "com" zone name server for the "example.com" NS RRset to verify it
- has the proper delegation information. This implementation performs
- this query to a zone's parent zone for each recursive query it
- receives that fails because of a completely unresponsive set of name
- servers for the target zone. Consider the effect when a popular zone
- experiences a catastrophic failure of all its name servers: now every
- recursive query for domain names in that zone sent to this recursive
- name server implementation results in a query to the failed zone's
- parent name servers. On one occasion when several dozen popular
- zones became unreachable, the query load on the com/net name servers
- increased by 50%.
-
- We believe this verification query is not reasonable. Consider the
- circumstances: When an iterative resolver is resolving a query for a
- domain name in a zone it has not previously searched, it uses the
- list of name servers in the referral from the target zone's parent.
- If on its first attempt to search the target zone, none of the name
- servers in the referral is reachable, a verification query to the
- parent would be pointless: this query to the parent would come so
- quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 5]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- to contain the same list of name servers. The chance of discovering
- any new information is slim.
-
- The other possibility is that the iterative resolver successfully
- contacts one of the target zone's name servers and then caches the NS
- RRset from the authority section of a response, the proper behavior
- according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
- the target zone is more trustworthy than delegation information from
- the parent zone. If, while processing a subsequent recursive query,
- the iterative resolver discovers that none of the name servers
- specified in the cached NS RRset is available or authoritative,
- querying the parent would be wrong. An NS RRset from the parent zone
- would now be less trustworthy than data already in the cache.
-
- For this query of the parent zone to be useful, the target zone's
- entire set of name servers would have to change AND the former set of
- name servers would have to be deconfigured or decommissioned AND the
- delegation information in the parent zone would have to be updated
- with the new set of name servers, all within the TTL of the target
- zone's NS RRset. We believe this scenario is uncommon:
- administrative best practices dictate that changes to a zone's set of
- name servers happen gradually when at all possible, with servers
- removed from the NS RRset left authoritative for the zone as long as
- possible. The scenarios that we can envision that would benefit from
- the parent requery behavior do not outweigh its damaging effects.
-
- This section should not be understood to claim that all queries to a
- zone's parent are bad. In some cases, such queries are not only
- reasonable but required. Consider the situation when required
- information, such as the address of a name server (i.e., the address
- record corresponding to the RDATA of an NS record), has timed out of
- an iterative resolver's cache before the corresponding NS record. If
- the name of the name server is below the apex of the zone, then the
- name server's address record is only available as glue in the parent
- zone. For example, consider this NS record:
-
- example.com. IN NS ns.example.com.
-
- If a cache has this NS record but not the address record for
- "ns.example.com", it is unable to contact the "example.com" zone
- directly and must query the "com" zone to obtain the address record.
- Note, however, that such a query would not have QTYPE=NS according to
- the standard resolution algorithm.
-
-2.1.1 Recommendation
-
- An iterative resolver MUST NOT send a query for the NS RRset of a
- non-responsive zone to any of the name servers for that zone's parent
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 6]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- zone. For the purposes of this injunction, a non-responsive zone is
- defined as a zone for which every name server listed in the zone's NS
- RRset:
-
- 1. is not authoritative for the zone (i.e., lame), or,
-
- 2. returns a server failure response (RCODE=2), or,
-
- 3. is dead or unreachable according to section 7.2 of RFC 2308 [4].
-
-
-2.2 Repeated queries to lame servers
-
- Section 2.1 describes a catastrophic failure: when every name server
- for a zone is unable to provide an answer for one reason or another.
- A more common occurrence is when a subset of a zone's name servers
- are unavailable or misconfigured. Different failure modes have
- different expected durations. Some symptoms indicate problems that
- are potentially transient; for example, various types of ICMP
- unreachable messages because a name server process is not running or
- a host or network is unreachable, or a complete lack of a response to
- a query. Such responses could be the result of a host rebooting or
- temporary outages; these events don't necessarily require any human
- intervention and can be reasonably expected to be temporary.
-
- Other symptoms clearly indicate a condition requiring human
- intervention, such as lame server: if a name server is misconfigured
- and not authoritative for a zone delegated to it, it is reasonable to
- assume that this condition has potential to last longer than
- unreachability or unresponsiveness. Consequently, repeated queries
- to known lame servers are not useful. In this case of a condition
- with potential to persist for a long time, a better practice would be
- to maintain a list of known lame servers and avoid querying them
- repeatedly in a short interval.
-
- It should also be noted, however, that some authoritative name server
- implementations appear to be lame only for queries of certain types
- as described in RFC 4074 [5]. In this case, it makes sense to retry
- the "lame" servers for other types of queries, particularly when all
- known authoritative name servers appear to be "lame".
-
-2.2.1 Recommendation
-
- Iterative resolvers SHOULD cache name servers that they discover are
- not authoritative for zones delegated to them (i.e. lame servers).
- If this caching is performed, lame servers MUST be cached against the
- specific query tuple <zone name, class, server IP address>. Zone
- name can be derived from the owner name of the NS record that was
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 7]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- referenced to query the name server that was discovered to be lame.
- Implementations that perform lame server caching MUST refrain from
- sending queries to known lame servers based on a time interval from
- when the server is discovered to be lame. A minimum interval of
- thirty minutes is RECOMMENDED.
-
- An exception to this recommendation occurs if all name servers for a
- zone are marked lame. In that case, the iterative resolver SHOULD
- temporarily ignore the servers' lameness status and query one or more
- servers. This behavior is a workaround for the type-specific
- lameness issue described in the previous section.
-
- Implementors should take care not to make lame server avoidance logic
- overly broad: note that a name server could be lame for a parent zone
- but not a child zone, e.g., lame for "example.com" but properly
- authoritative for "sub.example.com". Therefore a name server should
- not be automatically considered lame for subzones. In the case
- above, even if a name server is known to be lame for "example.com",
- it should be queried for QNAMEs at or below "sub.example.com" if an
- NS record indicates it should be authoritative for that zone.
-
-2.3 Inability to follow multiple levels of indirection
-
- Some iterative resolver implementations are unable to follow
- sufficient levels of indirection. For example, consider the
- following delegations:
-
- foo.example. IN NS ns1.example.com.
- foo.example. IN NS ns2.example.com.
-
- example.com. IN NS ns1.test.example.net.
- example.com. IN NS ns2.test.example.net.
-
- test.example.net. IN NS ns1.test.example.net.
- test.example.net. IN NS ns2.test.example.net.
-
- An iterative resolver resolving the name "www.foo.example" must
- follow two levels of indirection, first obtaining address records for
- "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
- address records for "ns1.example.com" or "ns2.example.com" in order
- to query those name servers for the address records of
- "www.foo.example". While this situation may appear contrived, we
- have seen multiple similar occurrences and expect more as new generic
- top-level domains (gTLDs) become active. We anticipate many zones in
- new gTLDs will use name servers in existing gTLDs, increasing the
- number of delegations using out-of-zone name servers.
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 8]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-2.3.1 Recommendation
-
- Clearly constructing a delegation that relies on multiple levels of
- indirection is not a good administrative practice. However, the
- practice is widespread enough to require that iterative resolvers be
- able to cope with it. Iterative resolvers SHOULD be able to handle
- arbitrary levels of indirection resulting from out-of-zone name
- servers. Iterative resolvers SHOULD implement a level-of-effort
- counter to avoid loops or otherwise performing too much work in
- resolving pathological cases.
-
- A best practice that avoids this entire issue of indirection is to
- name one or more of a zone's name servers in the zone itself. For
- example, if the zone is named "example.com", consider naming some of
- the name servers "ns{1,2,...}.example.com" (or similar).
-
-2.4 Aggressive retransmission when fetching glue
-
- When an authoritative name server responds with a referral, it
- includes NS records in the authority section of the response.
- According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
- server should also "put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not available
- from authoritative data or the cache." Some name server
- implementations take this address inclusion a step further with a
- feature called "glue fetching". A name server that implements glue
- fetching attempts to include address records for every NS record in
- the authority section. If necessary, the name server issues multiple
- queries of its own to obtain any missing address records.
-
- Problems with glue fetching can arise in the context of
- "authoritative-only" name servers, which only serve authoritative
- data and ignore requests for recursion. Such an entity will not
- normally generate any queries of its own. Instead it answers non-
- recursive queries from iterative resolvers looking for information in
- zones it serves. With glue fetching enabled, however, an
- authoritative server invokes an iterative resolver to look up an
- unknown address record to complete the additional section of a
- response.
-
- We have observed situations where the iterative resolver of a glue-
- fetching name server can send queries that reach other name servers,
- but is apparently prevented from receiving the responses. For
- example, perhaps the name server is authoritative-only and therefore
- its administrators expect it to receive only queries and not
- responses. Perhaps unaware of glue fetching and presuming that the
- name server's iterative resolver will generate no queries, its
- administrators place the name server behind a network device that
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 9]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- prevents it from receiving responses. If this is the case, all glue-
- fetching queries will go answered.
-
- We have observed name server implementations whose iterative
- resolvers retry excessively when glue-fetching queries are
- unanswered. A single com/net name server has received hundreds of
- queries per second from a single such source. Judging from the
- specific queries received and based on additional analysis, we
- believe these queries result from overly aggressive glue fetching.
-
-2.4.1 Recommendation
-
- Implementers whose name servers support glue fetching SHOULD take
- care to avoid sending queries at excessive rates. Implementations
- SHOULD support throttling logic to detect when queries are sent but
- no responses are received.
-
-2.5 Aggressive retransmission behind firewalls
-
- A common occurrence and one of the largest sources of repeated
- queries at the com/net and root name servers appears to result from
- resolvers behind misconfigured firewalls. In this situation, an
- iterative resolver is apparently allowed to send queries through a
- firewall to other name servers, but not receive the responses. The
- result is more queries than necessary because of retransmission, all
- of which are useless because the responses are never received. Just
- as with the glue-fetching scenario described in Section 2.4, the
- queries are sometimes sent at excessive rates. To make matters
- worse, sometimes the responses, sent in reply to legitimate queries,
- trigger an alarm on the originator's intrusion detection system. We
- are frequently contacted by administrators responding to such alarms
- who believe our name servers are attacking their systems.
-
- Not only do some resolvers in this situation retransmit queries at an
- excessive rate, but they continue to do so for days or even weeks.
- This scenario could result from an organization with multiple
- recursive name servers, only a subset of whose iterative resolvers'
- traffic is improperly filtered in this manner. Stub resolvers in the
- organization could be configured to query multiple recursive name
- servers. Consider the case where a stub resolver queries a filtered
- recursive name server first. The iterative resolver of this
- recursive name server sends one or more queries whose replies are
- filtered, so it can't respond to the stub resolver, which times out.
- Then the stub resolver retransmits to a recursive name server that is
- able to provide an answer. Since resolution ultimately succeeds the
- underlying problem might not be recognized or corrected. A popular
- stub resolver implementation has a very aggressive retransmission
- schedule, including simultaneous queries to multiple recursive name
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 10]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- servers, which could explain how such a situation could persist
- without being detected.
-
-2.5.1 Recommendation
-
- The most obvious recommendation is that administrators SHOULD take
- care not to place iterative resolvers behind a firewall that allows
- queries to pass through but not the resulting replies.
-
- Iterative resolvers SHOULD take care to avoid sending queries at
- excessive rates. Implementations SHOULD support throttling logic to
- detect when queries are sent but no responses are received.
-
-2.6 Misconfigured NS records
-
- Sometimes a zone administrator forgets to add the trailing dot on the
- domain names in the RDATA of a zone's NS records. Consider this
- fragment of the zone file for "example.com":
-
- $ORIGIN example.com.
- example.com. 3600 IN NS ns1.example.com ; Note missing
- example.com. 3600 IN NS ns2.example.com ; trailing dots
-
- The zone's authoritative servers will parse the NS RDATA as
- "ns1.example.com.example.com" and "ns2.example.com.example.com" and
- return NS records with this incorrect RDATA in responses, including
- typically the authority section of every response containing records
- from the "example.com" zone.
-
- Now consider a typical sequence of queries. An iterative resolver
- attempting to resolve address records for "www.example.com" with no
- cached information for this zone will query a "com" authoritative
- server. The "com" server responds with a referral to the
- "example.com" zone, consisting of NS records with valid RDATA and
- associated glue records. (This example assumes that the
- "example.com" zone delegation information is correct in the "com"
- zone.) The iterative resolver caches the NS RRset from the "com"
- server and follows the referral by querying one of the "example.com"
- authoritative servers. This server responds with the
- "www.example.com" address record in the answer section and,
- typically, the "example.com" NS records in the authority section and,
- if space in the message remains, glue address records in the
- additional section. According to Section 5.4 of RFC 2181 [3], NS
- records in the authority section of an authoritative answer are more
- trustworthy than NS records from the authority section of a non-
- authoritative answer. Thus the "example.com" NS RRset just received
- from the "example.com" authoritative server overrides the
- "example.com" NS RRset received moments ago from the "com"
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 11]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- authoritative server.
-
- But the "example.com" zone contains the erroneous NS RRset as shown
- in the example above. Subsequent queries for names in "example.com"
- will cause the iterative resolver to attempt to use the incorrect NS
- records and so it will try to resolve the nonexistent names
- "ns1.example.com.example.com" and "ns2.example.com.example.com". In
- this example, since all of the zone's name servers are named in the
- zone itself (i.e., "ns1.example.com.example.com" and
- "ns2.example.com.example.com" both end in "example.com") and all are
- bogus, the iterative resolver cannot reach any "example.com" name
- servers. Therefore attempts to resolve these names result in address
- record queries to the "com" authoritative servers. Queries for such
- obviously bogus glue address records occur frequently at the com/net
- name servers.
-
-2.6.1 Recommendation
-
- An authoritative server can detect this situation. A trailing dot
- missing from an NS record's RDATA always results by definition in a
- name server name that exists somewhere under the apex of the zone the
- NS record appears in. Note that further levels of delegation are
- possible, so a missing trailing dot could inadvertently create a name
- server name that actually exists in a subzone.
-
- An authoritative name server SHOULD issue a warning when one of a
- zone's NS records references a name server below the zone's apex when
- a corresponding address record does not exist in the zone AND there
- are no delegated subzones where the address record could exist.
-
-2.7 Name server records with zero TTL
-
- Sometimes a popular com/net subdomain's zone is configured with a TTL
- of zero on the zone's NS records, which prohibits these records from
- being cached and will result in a higher query volume to the zone's
- authoritative servers. The zone's administrator should understand
- the consequences of such a configuration and provision resources
- accordingly. A zero TTL on the zone's NS RRset, however, carries
- additional consequences beyond the zone itself: if an iterative
- resolver cannot cache a zone's NS records because of a zero TTL, it
- will be forced to query that zone's parent's name servers each time
- it resolves a name in the zone. The com/net authoritative servers do
- see an increased query load when a popular com/net subdomain's zone
- is configured with a TTL of zero on the zone's NS records.
-
- A zero TTL on an RRset expected to change frequently is extreme but
- permissible. A zone's NS RRset is a special case, however, because
- changes to it must be coordinated with the zone's parent. In most
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 12]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- zone parent/child relationships we are aware of, there is typically
- some delay involved in effecting changes. Further, changes to the
- set of a zone's authoritative name servers (and therefore to the
- zone's NS RRset) are typically relatively rare: providing reliable
- authoritative service requires a reasonably stable set of servers.
- Therefore an extremely low or zero TTL on a zone's NS RRset rarely
- makes sense, except in anticipation of an upcoming change. In this
- case, when the zone's administrator has planned a change and does not
- want iterative resolvers throughout the Internet to cache the NS
- RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1 Recommendation
-
- Because of the additional load placed on a zone's parent's
- authoritative servers resulting from a zero TTL on a zone's NS RRset,
- under such circumstances authoritative name servers SHOULD issue a
- warning when loading a zone.
-
-2.8 Unnecessary dynamic update messages
-
- The UPDATE message specified in RFC 2136 [6] allows an authorized
- agent to update a zone's data on an authoritative name server using a
- DNS message sent over the network. Consider the case of an agent
- desiring to add a particular resource record. Because of zone cuts,
- the agent does not necessarily know the proper zone to which the
- record should be added. The dynamic update process requires that the
- agent determine the appropriate zone so the UPDATE message can be
- sent to one of the zone's authoritative servers (typically the
- primary master as specified in the zone's SOA MNAME field).
-
- The appropriate zone to update is the closest enclosing zone, which
- cannot be determined only by inspecting the domain name of the record
- to be updated, since zone cuts can occur anywhere. One way to
- determine the closest enclosing zone entails walking up the name
- space tree by sending repeated UPDATE messages until success. For
- example, consider an agent attempting to add an address record with
- the name "foo.bar.example.com". The agent could first attempt to
- update the "foo.bar.example.com" zone. If the attempt failed, the
- update could be directed to the "bar.example.com" zone, then the
- "example.com" zone, then the "com" zone, and finally the root zone.
-
- A popular dynamic agent follows this algorithm. The result is many
- UPDATE messages received by the root name servers, the com/net
- authoritative servers, and presumably other TLD authoritative
- servers. A valid question is why the algorithm proceeds to send
- updates all the way to TLD and root name servers. This behavior is
- not entirely unreasonable: in enterprise DNS architectures with an
- "internal root" design, there could conceivably be private, non-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 13]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- public TLD or root zones that would be the appropriate targets for a
- dynamic update.
-
- A significant deficiency with this algorithm is that knowledge of a
- given UPDATE message's failure is not helpful in directing future
- UPDATE messages to the appropriate servers. A better algorithm would
- be to find the closest enclosing zone by walking up the name space
- with queries for SOA or NS rather than "probing" with UPDATE
- messages. Once the appropriate zone is found, an UPDATE message can
- be sent. In addition, the results of these queries can be cached to
- aid in determining closest enclosing zones for future updates. Once
- the closest enclosing zone is determined with this method, the update
- will either succeed or fail and there is no need to send further
- updates to higher-level zones. The important point is that walking
- up the tree with queries yields cacheable information, whereas
- walking up the tree by sending UPDATE messages does not.
-
-2.8.1 Recommendation
-
- Dynamic update agents SHOULD send SOA or NS queries to progressively
- higher-level names to find the closest enclosing zone for a given
- name to update. Only after the appropriate zone is found should the
- client send an UPDATE message to one of the zone's authoritative
- servers. Update clients SHOULD NOT "probe" using UPDATE messages by
- walking up the tree to progressively higher-level zones.
-
-2.9 Queries for domain names resembling IPv4 addresses
-
- The root name servers receive a significant number of A record
- queries where the QNAME looks like an IPv4 address. The source of
- these queries is unknown. It could be attributed to situations where
- a user believes an application will accept either a domain name or an
- IP address in a given configuration option. The user enters an IP
- address, but the application assumes any input is a domain name and
- attempts to resolve it, resulting in an A record lookup. There could
- also be applications that produce such queries in a misguided attempt
- to reverse map IP addresses.
-
- These queries result in Name Error (RCODE=3) responses. An iterative
- resolver can negatively cache such responses, but each response
- requires a separate cache entry, i.e., a negative cache entry for the
- domain name "192.0.2.1" does not prevent a subsequent query for the
- domain name "192.0.2.2".
-
-2.9.1 Recommendation
-
- It would be desirable for the root name servers not to have to answer
- these queries: they unnecessarily consume CPU resources and network
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 14]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- bandwidth. A possible solution is to delegate these numeric TLDs
- from the root zone to a separate set of servers to absorb the
- traffic. The "black hole servers" used by the AS 112 Project [8],
- which are currently delegated the in-addr.arpa zones corresponding to
- RFC 1918 [7] private use address space, would be a possible choice to
- receive these delegations. Of course, the proper and usual root zone
- change procedures would have to be followed to make such a change to
- the root zone.
-
-2.10 Misdirected recursive queries
-
- The root name servers receive a significant number of recursive
- queries (i.e., queries with the RD bit set in the header). Since
- none of the root servers offers recursion, the servers' response in
- such a situation ignores the request for recursion and the response
- probably does not contain the data the querier anticipated. Some of
- these queries result from users configuring stub resolvers to query a
- root server. (This situation is not hypothetical: we have received
- complaints from users when this configuration does not work as
- hoped.) Of course, users should not direct stub resolvers to use
- name servers that do not offer recursion, but we are not aware of any
- stub resolver implementation that offers any feedback to the user
- when so configured, aside from simply "not working".
-
-2.10.1 Recommendation
-
- When the IP address of a name server that supposedly offers recursion
- is configured in a stub resolver using an interactive user interface,
- the resolver could send a test query to verify that the server indeed
- supports recursion (i.e., verify that the response has the RA bit set
- in the header). The user could be immediately notified if the server
- is non-recursive.
-
- The stub resolver could also report an error, either through a user
- interface or in a log file, if the queried server does not support
- recursion. Error reporting SHOULD be throttled to avoid a
- notification or log message for every response from a non-recursive
- server.
-
-2.11 Suboptimal name server selection algorithm
-
- An entire document could be devoted to the topic of problems with
- different implementations of the recursive resolution algorithm. The
- entire process of recursion is woefully under specified, requiring
- each implementor to design an algorithm. Sometimes implementors make
- poor design choices that could be avoided if a suggested algorithm
- and best practices were documented, but that is a topic for another
- document.
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 15]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- Some deficiencies cause significant operational impact and are
- therefore worth mentioning here. One of these is name server
- selection by an iterative resolver. When an iterative resolver wants
- to contact one of a zone's authoritative name servers, how does it
- choose from the NS records listed in the zone's NS RRset? If the
- selection mechanism is suboptimal, queries are not spread evenly
- among a zone's authoritative servers. The details of the selection
- mechanism are up to the implementor, but we offer some suggestions.
-
-2.11.1 Recommendation
-
- This list is not conclusive, but reflects the changes that would
- produce the most impact in terms of reducing disproportionate query
- load among a zone's authoritative servers. I.e., these changes would
- help spread the query load evenly.
-
- o Do not make assumptions based on NS RRset order: all NS RRs SHOULD
- be treated equally. (In the case of the "com" zone, for example,
- most of the root servers return the NS record for "a.gtld-
- servers.net" first in the authority section of referrals.
- Apparently as a result, this server receives disproportionately
- more traffic than the other 12 authoritative servers for "com".)
-
- o Use all NS records in an RRset. (For example, we are aware of
- implementations that hard-coded information for a subset of the
- root servers.)
-
- o Maintain state and favor the best-performing of a zone's
- authoritative servers. A good definition of performance is
- response time. Non-responsive servers can be penalized with an
- extremely high response time.
-
- o Do not lock onto the best-performing of a zone's name servers. An
- iterative resolver SHOULD periodically check the performance of
- all of a zone's name servers to adjust its determination of the
- best-performing one.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 16]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-3. IANA considerations
-
- There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 17]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-4. Security considerations
-
- The iterative resolver misbehavior discussed in this document exposes
- the root and TLD name servers to increased risk of both intentional
- and unintentional denial of service attacks.
-
- We believe that implementation of the recommendations offered in this
- document will reduce the amount of unnecessary traffic seen at root
- and TLD name servers, thus reducing the opportunity for an attacker
- to use such queries to his or her advantage.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 18]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-5. Internationalization considerations
-
- There are no new internationalization considerations introduced by
- this memo.
-
-6. Informative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
- Queries for IPv6 Addresses", RFC 4074, May 2005.
-
- [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
- Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
- Lear, "Address Allocation for Private Internets", BCP 5,
- RFC 1918, February 1996.
-
- [8] <http://www.as112.net>
-
-
-Authors' Addresses
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: mlarson@verisign.com
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 19]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
- Piet Barber
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- Email: pbarber@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 20]
-\f
-Internet-Draft Observed DNS Resolution Misbehavior July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Larson & Barber Expires January 18, 2006 [Page 21]
-\f
+++ /dev/null
-
-
-
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: September 2, 2005 R. Gieben
- NLnet Labs
- March 2005
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-04.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 September 2, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document describes a set of practices for operating the DNS with
- security extensions (DNSSEC). The target audience is zone
- administrators deploying DNSSEC.
-
- The document discusses operational aspects of using keys and
- signatures in the DNS. It discusses issues as key generation, key
- storage, signature generation, key rollover and related policies.
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 1]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 4
- 1.2 Time Definitions . . . . . . . . . . . . . . . . . . . . . 5
- 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5
- 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6
- 3.1 Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6
- 3.1.1 Motivations for the KSK and ZSK Separation . . . . . . 6
- 3.1.2 KSKs for high level zones . . . . . . . . . . . . . . 7
- 3.2 Randomness . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3 Key Effectivity Period . . . . . . . . . . . . . . . . . . 8
- 3.4 Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9
- 3.5 Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 9
- 3.6 Private Key Storage . . . . . . . . . . . . . . . . . . . 10
- 4. Signature generation, Key Rollover and Related Policies . . . 11
- 4.1 Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 11
- 4.1.1 Time Considerations . . . . . . . . . . . . . . . . . 11
- 4.2 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 13
- 4.2.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 13
- 4.2.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 17
- 4.2.3 Difference Between ZSK and KSK Rollovers . . . . . . . 18
- 4.2.4 Automated Key Rollovers . . . . . . . . . . . . . . . 19
- 4.3 Planning for Emergency Key Rollover . . . . . . . . . . . 19
- 4.3.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . 20
- 4.3.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . 20
- 4.3.3 Compromises of Keys Anchored in Resolvers . . . . . . 20
- 4.4 Parental Policies . . . . . . . . . . . . . . . . . . . . 21
- 4.4.1 Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . 21
- 4.4.2 Storing Keys or Hashes? . . . . . . . . . . . . . . . 21
- 4.4.3 Security Lameness . . . . . . . . . . . . . . . . . . 22
- 4.4.4 DS Signature Validity Period . . . . . . . . . . . . . 22
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23
- 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
- 7.1 Normative References . . . . . . . . . . . . . . . . . . . 24
- 7.2 Informative References . . . . . . . . . . . . . . . . . . 24
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 25
- B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 26
- C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 26
- D. Document Details and Changes . . . . . . . . . . . . . . . . . 29
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 29
- D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 29
- D.3 draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 29
- D.4 draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 29
- D.5 draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 30
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 2]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- Intellectual Property and Copyright Statements . . . . . . . . 31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 3]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- and system administrators gained experience about operating the DNS
- with security extensions (DNSSEC). This document translates these
- experiences into a set of practices for zone administrators. At the
- time of writing, there exists very little experience with DNSSEC in
- production environments; this document should therefore explicitly
- not be seen as representing 'Best Current Practices'.
-
- The procedures herein are focused on the maintenance of signed zones
- (i.e. signing and publishing zones on authoritative servers). It is
- intended that maintenance of zones such as resigning or key rollovers
- be transparent to any verifying clients on the Internet.
-
- The structure of this document is as follows. In Section 2 we
- discuss the importance of keeping the "chain of trust" intact.
- Aspects of key generation and storage of private keys are discussed
- in Section 3; the focus in this section is mainly on the private part
- of the key(s). Section 4 describes considerations concerning the
- public part of the keys. Since these public keys appear in the DNS
- one has to take into account all kinds of timing issues, which are
- discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the
- rollover, or which, of keys. Finally Section 4.4 discusses
- considerations on how parents deal with their children's public keys
- in order to maintain chains of trust.
-
- The typographic conventions used in this document are explained in
- Appendix C.
-
- Since this is a document with operational suggestions and there are
- no protocol specifications, the RFC2119 [4] language does not apply.
-
- This document obsoletes RFC2541 [7]
-
-1.1 The Use of the Term 'key'
-
- It is assumed that the reader is familiar with the concept of
- asymmetric keys on which DNSSEC is based (Public Key Cryptography
- [11]). Therefore, this document will use the term 'key' rather
- loosely. Where it is written that 'a key is used to sign data' it is
- assumed that the reader understands that it is the private part of
- the key-pair that is used for signing. It is also assumed that the
- reader understands that the public part of the key-pair is published
- in the DNSKEY resource record and that it is the public part that is
- used in key-exchanges.
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 4]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-1.2 Time Definitions
-
- In this document we will be using a number of time related terms.
- The following definitions apply:
- o "Signature validity period"
- The period that a signature is valid. It starts at the time
- specified in the signature inception field of the RRSIG RR and
- ends at the time specified in the expiration field of the RRSIG
- RR.
- o "Signature publication period"
- Time after which a signature (made with a specific key) is
- replaced with a new signature (made with the same key). This
- replacement takes place by publishing the relevant RRSIG in the
- master zone file.
- After one stopped publishing an RRSIG in a zone it may take a
- while before the RRSIG has expired from caches and has actually
- been removed from the DNS.
- o "Key effectivity period"
- The period which a key pair is expected to be effective. This
- period is defined as the time between the first inception time
- stamp and the last expiration date of any signature made with
- this key.
- The key effectivity period can span multiple signature validity
- periods.
- o "Maximum/Minimum Zone TTL"
- The maximum or minimum value of the TTLs from the complete set
- of RRs in a zone.
-
-2. Keeping the Chain of Trust Intact
-
- Maintaining a valid chain of trust is important because broken chains
- of trust will result in data being marked as Bogus (as defined in [2]
- section 5), which may cause entire (sub)domains to become invisible
- to verifying clients. The administrators of secured zones have to
- realize that their zone is, to their clients, part of a chain of
- trust.
-
- As mentioned in the introduction, the procedures herein are intended
- to ensure maintenance of zones, such as resigning or key rollovers,
- will be transparent to the verifying clients on the Internet.
-
- Administrators of secured zones will have to keep in mind that data
- published on an authoritative primary server will not be immediately
- seen by verifying clients; it may take some time for the data to be
- transfered to other secondary authoritative nameservers and clients
- may be fetching data from caching non-authoritative servers.
-
- For the verifying clients it is important that data from secured
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 5]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- zones can be used to build chains of trust regardless of whether the
- data came directly from an authoritative server, a caching nameserver
- or some middle box. Only by carefully using the available timing
- parameters can a zone administrator assure that the data necessary
- for verification can be obtained.
-
- The responsibility for maintaining the chain of trust is shared by
- administrators of secured zones in the chain of trust. This is most
- obvious in the case of a 'key compromise' when a trade off between
- maintaining a valid chain of trust and replacing the compromised keys
- as soon as possible must be made. Then zone administrators will have
- to make a trade off, between keeping the chain of trust intact -
- thereby allowing for attacks with the compromised key - or to
- deliberately break the chain of trust and making secured sub domains
- invisible to security aware resolvers. Also see Section 4.3.
-
-3. Keys Generation and Storage
-
- This section describes a number of considerations with respect to the
- security of keys. It deals with the generation, effectivity period,
- size and storage of private keys.
-
-3.1 Zone and Key Signing Keys
-
- The DNSSEC validation protocol does not distinguish between DNSKEYs.
- All DNSKEYs can be used during the validation. In practice operators
- use Key Signing and Zone Signing Keys and use the so-called (Secure
- Entry Point) SEP flag to distinguish between them during operations.
- The dynamics and considerations are discussed below.
-
- To make zone resigning and key rollover procedures easier to
- implement, it is possible to use one or more keys as Key Signing Keys
- (KSK). These keys will only sign the apex DNSKEY RR set in a zone.
- Other keys can be used to sign all the RRsets in a zone and are
- referred to as Zone Signing Keys (ZSK). In this document we assume
- that KSKs are the subset of keys that are used for key exchanges with
- the parent and potentially for configuration as trusted anchors - the
- SEP keys. In this document we assume a one-to-one mapping between
- KSK and SEP keys and we assume the SEP flag [1] to be set on all
- KSKs.
-
-3.1.1 Motivations for the KSK and ZSK Separation
-
- Differentiating between the KSK and ZSK functions has several
- advantages:
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 6]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- o No parent/child interaction is required when ZSKs are updated.
- o The KSK can be made stronger (i.e. using more bits in the key
- material). This has little operational impact since it is only
- used to sign a small fraction of the zone data. Also when
- verifying the KSK is only used to verify the zone's keyset.
- o As the KSK is only used to sign a key set, which is most probably
- updated less frequently than other data in the zone, it can be
- stored separately from and in a safer location than the ZSK.
- o A KSK can have a longer key effectivity period.
-
- For almost any method of key management and zone signing the KSK is
- used less frequently than the ZSK. Once a key set is signed with the
- KSK all the keys in the key set can be used as ZSK. If a ZSK is
- compromised, it can be simply dropped from the key set. The new key
- set is then resigned with the KSK.
-
- Given the assumption that for KSKs the SEP flag is set, the KSK can
- be distinguished from a ZSK by examining the flag field in the DNSKEY
- RR. If the flag field is an odd number it is a KSK. If it is an
- even number it is a ZSK.
-
- The zone-signing key can be used to sign all the data in a zone on a
- regular basis. When a zone-signing key is to be rolled, no
- interaction with the parent is needed. This allows for "Signature
- Validity Periods" on the order of days.
-
- The key-signing key is only to be used to sign the DNSKEY RRs in a
- zone. If a key-signing key is to be rolled over, there will be
- interactions with parties other than the zone administrator. These
- can include the registry of the parent zone or administrators of
- verifying resolvers that have the particular key configured as
- trusted entry points. Hence, the key effectivity period of these
- keys can and should be made much longer. Although, given a long
- enough key, the Key Usage Time can be on the order of years we
- suggest planning for a key effectivity of the order of a few months
- so that a key rollover remains an operational routine.
-
-3.1.2 KSKs for high level zones
-
- Higher level zones are generally more sensitive than lower level
- zones. Anyone controlling or breaking the security of a zone thereby
- obtains authority over all of its sub domains (except in the case of
- resolvers that have locally configured the public key of a sub
- domain). Therefore, extra care should be taken with high level zones
- and strong keys used.
-
- The root zone is the most critical of all zones. Someone controlling
- or compromising the security of the root zone would control the
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 7]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- entire DNS name space of all resolvers using that root zone (except
- in the case of resolvers that have locally configured the public key
- of a sub domain). Therefore, the utmost care must be taken in the
- securing of the root zone. The strongest and most carefully handled
- keys should be used. The root zone private key should always be kept
- off line.
-
- Many resolvers will start at a root server for their access to and
- authentication of DNS data. Securely updating the trust anchors in
- an enormous population of resolvers around the world will be
- extremely difficult.
-
-3.2 Randomness
-
- Careful generation of all keys is a sometimes overlooked but
- absolutely essential element in any cryptographically secure system.
- The strongest algorithms used with the longest keys are still of no
- use if an adversary can guess enough to lower the size of the likely
- key space so that it can be exhaustively searched. Technical
- suggestions for the generation of random keys will be found in
- RFC1750 [3]. One should carefully assess if the random number
- generator used during key generation adheres to these suggestions.
-
- Keys with a long effectivity period are particularly sensitive as
- they will represent a more valuable target and be subject to attack
- for a longer time than short period keys. It is strongly recommended
- that long term key generation occur off-line in a manner isolated
- from the network via an air gap or, at a minimum, high level secure
- hardware.
-
-3.3 Key Effectivity Period
-
- For various reasons keys in DNSSEC need to be changed once in a
- while. The longer a key is in use, the greater the probability that
- it will have been compromised through carelessness, accident,
- espionage, or cryptanalysis. Furthermore when key rollovers are too
- rare an event, they will not become part of the operational habit and
- there is risk that nobody on-site will remember the procedure for
- rollover when the need is there.
-
- For Key Signing Keys a reasonable key effectivity period is 13
- months, with the intent to replace them after 12 months. An intended
- key effectivity period of a month is reasonable for Zone Signing
- Keys.
-
- Using these recommendations will lead to rollovers occurring
- frequently enough to become part of 'operational habits'; the
- procedure does not have to be reinvented every time a key is
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 8]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- replaced.
-
- Key effectivity periods can be made very short, as in the order of a
- few minutes. But when replacing keys one has to take the
- considerations from Section 4.1 and Section 4.2 into account.
-
-3.4 Key Algorithm
-
- There are currently three different types of algorithms that can be
- used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter
- is fairly new and still needs to be standardized for usage in DNSSEC.
-
- RSA has been developed in an open and transparent manner. As the
- patent on RSA expired in 2000, its use is now also free.
-
- DSA has been developed by NIST. The creation of signatures is
- roughly done at the same speed as with RSA, but is 10 to 40 times as
- slow for verification [11].
-
- We suggest the use of RSA/SHA-1 as the preferred algorithm for the
- key. The current known attacks on RSA can be defeated by making your
- key longer. As the MD5 hashing algorithm is showing (theoretical)
- cracks, we recommend the usage of SHA1.
-
- In 2005 some discoveries were made that SHA-1 also has some
- weaknesses. Currently SHA-1 is strong enough for DNSSEC. It is
- expected that a new hashing algorithm is rolled out, before any
- attack becomes practical.
-
-3.5 Key Sizes
-
- When choosing key sizes, zone administrators will need to take into
- account how long a key will be used and how much data will be signed
- during the key publication period. It is hard to give precise
- recommendations but Lenstra and Verheul [10] supplied the following
- table with lower bound estimates for cryptographic key sizes. Their
- recommendations are based on a set of explicitly formulated parameter
- settings, combined with existing data points about cryptographic
- systems. For details we refer to the original paper.
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 9]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- Year RSA Key Sizes Year RSA Key Sizes
-
- 2000 952 2015 1613
- 2001 990 2016 1664
- 2002 1028 2017 1717
- 2003 1068 2018 1771
- 2004 1108 2019 1825
-
-
- 2005 1149 2020 1881
- 2006 1191 2021 1937
- 2007 1235 2022 1995
- 2008 1279 2023 2054
- 2009 1323 2024 2113
-
-
- 2026 2236 2025 2174
- 2010 1369 2027 2299
- 2011 1416 2028 2362
- 2012 1464 2029 2427
- 2013 1513
- 2014 1562
-
- For example, should you wish your key to last three years from 2003,
- check the RSA key size values for 2006 in this table. In this case
- it should be at least 1191 bits.
-
- Please keep in mind that nobody can see into the future, and that
- these key lengths are only provided here as a guide.
-
- When determining a key size one should take into account that a large
- key will be slower during generation and verification. For RSA,
- verification, the most common operation, will vary roughly with the
- square of the key size; signing will vary with the cube of the key
- size length; and key generation will vary with the fourth power of
- the modulus length. Besides larger keys will increase the sizes of
- the RRSIG and DNSKEY records and will therefore increase the chance
- of DNS UDP packet overflow. Also see Section 3.1.1 for a discussion
- of how keys serving different roles (ZSK v. KSK) may need different
- key strengths.
-
-3.6 Private Key Storage
-
- It is recommended that, where possible, zone private keys and the
- zone file master copy be kept and used in off-line, non-network
- connected, physically secure machines only. Periodically an
- application can be run to add authentication to a zone by adding
- RRSIG and NSEC RRs. Then the augmented file can be transferred,
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 10]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- perhaps by sneaker-net, to the networked zone primary server machine.
-
- The ideal situation is to have a one way information flow to the
- network to avoid the possibility of tampering from the network.
- Keeping the zone master file on-line on the network and simply
- cycling it through an off-line signer does not do this. The on-line
- version could still be tampered with if the host it resides on is
- compromised. For maximum security, the master copy of the zone file
- should be off net and should not be updated based on an unsecured
- network mediated communication.
-
- In general keeping a zone-file off-line will not be practical and the
- machines on which zone files are maintained will be connected to a
- network. Operators are advised to take security measures to shield
- unauthorized access to the master copy.
-
- For dynamically updated secured zones [5] both the master copy and
- the private key that is used to update signatures on updated RRs will
- need to be on line.
-
-4. Signature generation, Key Rollover and Related Policies
-
-4.1 Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA RR's refresh,
- retry and expiration timers are counters that are used to determine
- the time elapsed after a slave server synchronized (or tried to
- synchronize) with a master server. The Time to Live (TTL) value and
- the SOA RR minimum TTL parameter [6] are used to determine how long a
- forwarder should cache data after it has been fetched from an
- authoritative server. By using a signature validity period, DNSSEC
- introduces the notion of an absolute time in the DNS. Signatures in
- DNSSEC have an expiration date after which the signature is marked as
- invalid and the signed data is to be considered Bogus.
-
-4.1.1 Time Considerations
-
- Because of the expiration of signatures, one should consider the
- following:
- o We suggest the Maximum Zone TTL of your zone data to be a fraction
- of your signature validity period.
- If the TTL would be of similar order as the signature validity
- period, then all RRsets fetched during the validity period
- would be cached until the signature expiration time. Section
- 7.1 of [2] suggests that "the resolver may use the time
- remaining before expiration of the signature validity period of
- a signed RRset as an upper bound for the TTL". As a result
- query load on authoritative servers would peak at signature
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 11]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- expiration time, as this is also the time at which records
- simultaneously expire from caches.
- To avoid query load peaks we suggest the TTL on all the RRs in
- your zone to be at least a few times smaller than your
- signature validity period.
- o We suggest the signature publication period to be at least one
- maximum TTL smaller than the signature validity period.
- Resigning a zone shortly before the end of the signature
- validity period may cause simultaneous expiration of data from
- caches. This in turn may lead to peaks in the load on
- authoritative servers.
- o We suggest the minimum zone TTL to be long enough to both fetch
- and verify all the RRs in the authentication chain. A low TTL
- could cause two problems:
- 1. During validation, some data may expire before the
- validation is complete. The validator should be able to keep
- all data, until is completed. This applies to all RRs needed
- to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
- final answers i.e. the RR set that is returned for the initial
- query.
- 2. Frequent verification causes load on recursive nameservers.
- Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
- caching. The TTL on those should be relatively long.
- o Slave servers will need to be able to fetch newly signed zones
- well before the RRSIGs in the zone served by the slave server pass
- their signature expiration time.
- When a slave server is out of sync with its master and data in
- a zone is signed by expired signatures it may be better for the
- slave server not to give out any answer.
- Normally a slave server that is not able to contact a master
- server for an extended period will expire a zone. When that
- happens the zone will not respond on queries. The time of
- expiration is set in the SOA record and is relative to the last
- successful refresh between the master and the slave server.
- There exists no coupling between the signature expiration of
- RRSIGs in the zone and the expire parameter in the SOA.
- If the server serves a DNSSEC zone than it may well happen that
- the signatures expire well before the SOA expiration timer
- counts down to zero. It is not possible to completely prevent
- this from happening by tweaking the SOA parameters.
- However, the effects can be minimized where the SOA expiration
- time is equal or smaller than the signature validity period.
- The consequence of an authoritative server not being able to
- update a zone, whilst that zone includes expired signatures, is
- that non-secure resolvers will continue to be able to resolve
- data served by the particular slave servers while security
- aware resolvers will experience problems because of answers
- being marked as Bogus.
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 12]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- We suggest the SOA expiration timer being approximately one
- third or one fourth of the signature validity period. It will
- allow problems with transfers from the master server to be
- noticed before the actual signature time out.
- We also suggest that operators of nameservers that supply
- secondary services develop 'watch dogs' to spot upcoming
- signature expirations in zones they slave, and take appropriate
- action.
- When determining the value for the expiration parameter one has
- to take the following into account: What are the chances that
- all my secondary zones expire; How quickly can I reach an
- administrator of secondary servers to load a valid zone? All
- these arguments are not DNSSEC specific but may influence the
- choice of your signature validity intervals.
-
-4.2 Key Rollovers
-
- A DNSSEC key cannot be used forever (see Section 3.3). So key
- rollovers -- or supercessions, as they are sometimes called -- are a
- fact of life when using DNSSEC. Zone administrators who are in the
- process of rolling their keys have to take into account that data
- published in previous versions of their zone still lives in caches.
- When deploying DNSSEC, this becomes an important consideration;
- ignoring data that may be in caches may lead to loss of service for
- clients.
-
- The most pressing example of this is when zone material signed with
- an old key is being validated by a resolver which does not have the
- old zone key cached. If the old key is no longer present in the
- current zone, this validation fails, marking the data Bogus.
- Alternatively, an attempt could be made to validate data which is
- signed with a new key against an old key that lives in a local cache,
- also resulting in data being marked Bogus.
-
-4.2.1 Zone-signing Key Rollovers
-
- For zone-signing key rollovers there are two ways to make sure that
- during the rollover data still cached can be verified with the new
- key sets or newly generated signatures can be verified with the keys
- still in caches. One schema, described in Section 4.2.1.2, uses
- double signatures; the other uses key pre-publication
- (Section 4.2.1.1). The pros, cons and recommendations are described
- in Section 4.2.1.3.
-
-4.2.1.1 Pre-publish key set Rollover
-
- This section shows how to perform a ZSK rollover without the need to
- sign all the data in a zone twice - the so-called "pre-publish
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 13]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- rollover".This method has advantages in the case of a key compromise.
- If the old key is compromised, the new key has already been
- distributed in the DNS. The zone administrator is then able to
- quickly switch to the new key and remove the compromised key from the
- zone. Another major advantage is that the zone size does not double,
- as is the case with the double signature ZSK rollover. A small
- "HOWTO" for this kind of rollover can be found in Appendix B.
-
- normal pre-roll roll after
-
- SOA0 SOA1 SOA2 SOA3
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
- DNSKEY 10 is used to sign all the data of the zone, the zone-
- signing key.
- pre-roll: DNSKEY 11 is introduced into the key set. Note that no
- signatures are generated with this key yet, but this does not
- secure against brute force attacks on the public key. The minimum
- duration of this pre-roll phase is the time it takes for the data
- to propagate to the authoritative servers plus TTL value of the
- key set. This equates to two times the Maximum Zone TTL.
- roll: At the rollover stage (SOA serial 2) DNSKEY 11 is used to sign
- the data in the zone exclusively (i.e. all the signatures from
- DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
- in the key set. This way data that was loaded into caches from
- version 1 of the zone can still be verified with key sets fetched
- from version 2 of the zone.
- The minimum time that the key set including DNSKEY 10 is to be
- published is the time that it takes for zone data from the
- previous version of the zone to expire from old caches i.e. the
- time it takes for this zone to propagate to all authoritative
- servers plus the Maximum Zone TTL value of any of the data in the
- previous version of the zone.
- after: DNSKEY 10 is removed from the zone. The key set, now only
- containing DNSKEY 1 and DNSKEY 11 is resigned with the DNSKEY 1.
-
- The above scheme can be simplified by always publishing the "future"
- key immediately after the rollover. The scheme would look as follows
- (we show two rollovers); the future key is introduced in "after" as
- DNSKEY 12 and again a newer one, numbered 13, in "2nd after":
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 14]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- normal roll after
-
- SOA0 SOA2 SOA3
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11 DNSKEY12
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- 2nd roll 2nd after
-
- SOA4 SOA5
- RRSIG12(SOA4) RRSIG12(SOA5)
-
- DNSKEY1 DNSKEY1
- DNSKEY11 DNSKEY12
- DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG12(DNSKEY) RRSIG12(DNSKEY)
-
-
- Note that the key introduced after the rollover is not used for
- production yet; the private key can thus be stored in a physically
- secure manner and does not need to be 'fetched' every time a zone
- needs to be signed.
-
-4.2.1.2 Double Signature Zone-signing Key Rollover
-
- This section shows how to perform a ZSK key rollover using the double
- zone data signature scheme, aptly named "double sig rollover".
-
- During the rollover stage the new version of the zone file will need
- to propagate to all authoritative servers and the data that exists in
- (distant) caches will need to expire, requiring at least the maximum
- Zone TTL.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 15]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
- RRSIG11(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11
- RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
- RRSIG11(DNSKEY)
-
- normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
- DNSKEY 10 is used to sign all the data of the zone, the zone-
- signing key.
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the key set and all the data in the zone is signed with
- DNSKEY 10 and DNSKEY 11. The rollover period will need to exist
- until all data from version 0 of the zone has expired from remote
- caches. This will take at least the maximum Zone TTL of version 0
- of the zone.
- after: DNSKEY 10 is removed from the zone. All the signatures from
- DNSKEY 10 are removed from the zone. The key set, now only
- containing DNSKEY 11, is resigned with DNSKEY 1.
-
- At every instance, RRSIGs from the previous version of the zone can
- be verified with the DNSKEY RRset from the current version and the
- other way around. The data from the current version can be verified
- with the data from the previous version of the zone. The duration of
- the rollover phase and the period between rollovers should be at
- least the "Maximum Zone TTL".
-
- Making sure that the rollover phase lasts until the signature
- expiration time of the data in version 0 of the zone is recommended.
- This way all caches are cleared of the old signatures. However, this
- date could be considerably longer than the Maximum Zone TTL, making
- the rollover a lengthy procedure.
-
- Note that in this example we assumed that the zone was not modified
- during the rollover. New data can be introduced in the zone as long
- as it is signed with both keys.
-
-4.2.1.3 Pros and Cons of the Schemes
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 16]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- Pre-publish-key set rollover: This rollover does not involve signing
- the zone data twice. Instead, before the actual rollover, the new
- key is published in the key set and thus available for
- cryptanalysis attacks. A small disadvantage is that this process
- requires four steps. Also the pre-publish scheme involves more
- parental work when used for KSK rollovers as explained in
- Section 4.2.
- Double signature rollover: The drawback of this signing scheme is
- that during the rollover the number of signatures in your zone
- doubles, this may be prohibitive if you have very big zones. An
- advantage is that it only requires three steps.
-
-4.2.2 Key-signing Key Rollovers
-
- For the rollover of a key-signing key the same considerations as for
- the rollover of a zone-signing key apply. However we can use a
- double signature scheme to guarantee that old data (only the apex key
- set) in caches can be verified with a new key set and vice versa.
-
- Since only the key set is signed with a KSK, zone size considerations
- do not apply.
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
-
- DNSKEY1 DNSKEY1 DNSKEY2
- DNSKEY2
- DNSKEY10 DNSKEY10 DNSKEY10
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
- RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
- normal: Version 0 of the zone. The parental DS points to DNSKEY1.
- Before the rollover starts the child will have to verify what the
- TTL is of the DS RR that points to DNSKEY1 - it is needed during
- the rollover and we refer to the value as TTL_DS.
- roll: During the rollover phase the zone administrator generates a
- second KSK, DNSKEY2. The key is provided to the parent and the
- child will have to wait until a new DS RR has been generated that
- points to DNSKEY2. After that DS RR has been published on all
- servers authoritative for the parent's zone, the zone
- administrator has to wait at least TTL_DS to make sure that the
- old DS RR has expired from caches.
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 17]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- after: DNSKEY1 has been removed.
-
- The scenario above puts the responsibility for maintaining a valid
- chain of trust with the child. It also is based on the premises that
- the parent only has one DS RR (per algorithm) per zone. An
- alternative mechanism has been considered. Using an established
- trust relation, the interaction can be performed in-band, and the
- removal of the keys by the child can possibly be signaled by the
- parent. In this mechanism there are periods where there are two DS
- RRs at the parent. Since at the moment of writing the protocol for
- this interaction has not been developed further discussion is out of
- scope for this document.
-
-4.2.3 Difference Between ZSK and KSK Rollovers
-
- Note that KSK rollovers and ZSK rollovers are different. A zone-key
- rollover can be handled in two different ways: pre-publish (Section
- Section 4.2.1.1) and double signature (Section Section 4.2.1.2).
-
- As the KSK is used to validate the key set and because the KSK is not
- changed during a ZSK rollover, a cache is able to validate the new
- key set of the zone. The pre-publish method would work for a KSK
- rollover. The record that are to be pre-published are the parental
- DS RRs.
-
- The pre-publish method has some drawbacks. We first describe the
- rollover scheme and then indicate these drawbacks.
-
- normal pre-roll roll after
- Parent:
- SOA0 SOA1 SOA2 SOA3
- RRSIGpar(SOA0) RRSIGpar(SOA1) RRSIGpar(SOA2) RRSIGpar(SOA3)
- DS1 DS1 DS1 DS2
- DS2 DS2
- RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS) RRSIGpar(DS)
-
-
-
- Child:
- SOA0 SOA0 SOA1 SOA1
- RRSIG10(SOA0) RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY2 DNSKEY2
-
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY10
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 18]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- When the child zone wants to roll it notifies the parent during the
- pre-roll phase and submits the new key to the parent. The parent
- publishes DS1 and DS2, pointing to DNSKEY1 and DNSKEY2 respectively.
- During the rollover, which can take place as soon as the new DS set
- propagated through the DNS, the child replaces DNSKEY1 with DNSKEY2.
- Immediately after that it can notify the parent that the old DS
- record can be deleted.
-
- The drawbacks of these scheme are that during the pre-roll phase the
- parent cannot verify the match between the DS RR and DNSKEY2 using
- the DNS. Besides, we introduce a "security lame" DS record
- Section 4.4.3. Finally the child-parent interaction consists of two
- steps. The "double signature" method only needs one interaction.
-
-4.2.4 Automated Key Rollovers
-
- As keys must be renewed periodically, there is some motivation to
- automate the rollover process. Consider that:
-
- o ZSK rollovers are easy to automate as only the local zone is
- involved.
- o A KSK rollover needs interaction between the parent and child.
- Data exchange is needed to provide the new keys to the parent,
- consequently, this data must be authenticated and integrity must
- be guaranteed in order to avoid attacks on the rollover.
- o All time and TTL considerations presented in Section 4.2 apply to
- an automated rollover.
-
-4.3 Planning for Emergency Key Rollover
-
- This section deals with preparation for a possible key compromise.
- Our advice is to have a documented procedure ready for when a key
- compromise is suspected or confirmed.
-
- When the private material of one of your keys is compromised it can
- be used for as long as a valid authentication chain exists. An
- authentication chain remains intact for:
- o as long as a signature over the compromised key in the
- authentication chain is valid,
- o as long as a parental DS RR (and signature) points to the
- compromised key,
- o as long as the key is anchored in a resolver and is used as a
- starting point for validation. (This is generally the hardest to
- update.)
-
- While an authentication chain to your compromised key exists, your
- name-space is vulnerable to abuse by anyone who has obtained
- illegitimate possession of the key.Zone operators have to make a
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 19]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- trade off if the abuse of the compromised key is worse than having
- data in caches that cannot be validated. If the zone operator
- chooses to break the authentication chain to the compromised key,
- data in caches signed with this key cannot be validated. However, if
- the zone administrator chooses to take the path of a regular roll-
- over, the malicious key holder can spoof data so that it appears to
- be valid. Note that this kind of attack is more likely to occur in a
- localized part of the network topology i.e. downstream from where the
- spoof takes place.
-
-
-4.3.1 KSK Compromise
-
- When the KSK has been compromised the parent must be notified as soon
- as possible using secure means. The key set of the zone should be
- resigned as soon as possible. Care must be taken to not break the
- authentication chain. The local zone can only be resigned with the
- new KSK after the parent's zone has created and reloaded its zone
- with the DS created from the new KSK. Before this update takes place
- it would be best to drop the security status of a zone all together:
- the parent removes the DS of the child at the next zone update.
- After that the child can be made secure again.
-
- An additional danger of a key compromise is that the compromised key
- can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
- rollover at the parent. When that happens the domain can be in
- dispute. An authenticated out of band and secure notify mechanism to
- contact a parent is needed in this case.
-
-4.3.2 ZSK Compromise
-
- Primarily because there is no parental interaction required when a
- ZSK is compromised, the situation is less severe than with with a KSK
- compromise. The zone must still be resigned with a new ZSK as soon
- as possible. As this is a local operation and requires no
- communication between the parent and child this can be achieved
- fairly quickly. However, one has to take into account that just as
- with a normal rollover the immediate disappearance from the old
- compromised key may lead to verification problems. The pre-
- publication scheme as discussed above minimizes such problems.
-
-4.3.3 Compromises of Keys Anchored in Resolvers
-
- A key can also be pre-configured in resolvers. For instance, if
- DNSSEC is successfully deployed the root key may be pre-configured in
- most security aware resolvers.
-
- If trust-anchor keys are compromised, the resolvers using these keys
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 20]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- should be notified of this fact. Zone administrators may consider
- setting up a mailing list to communicate the fact that a SEP key is
- about to be rolled over. This communication will of course need to
- be authenticated e.g. by using digital signatures.
-
- End-users faced with the task of updating an anchored key should
- always validate the new key. New keys should be authenticated out of
- the DNS, for example, looking them up on an SSL secured announcement
- website.
-
-4.4 Parental Policies
-
-4.4.1 Initial Key Exchanges and Parental Policies Considerations
-
- The initial key exchange is always subject to the policies set by the
- parent (or its registry). When designing a key exchange policy one
- should take into account that the authentication and authorization
- mechanisms used during a key exchange should be as strong as the
- authentication and authorization mechanisms used for the exchange of
- delegation information between parent and child. I.e. there is no
- implicit need in DNSSEC to make the authentication process stronger
- than it was in DNS.
-
- Using the DNS itself as the source for the actual DNSKEY material,
- with an off-band check on the validity of the DNSKEY, has the benefit
- that it reduces the chances of user error. A parental DNSKEY
- download tool can make use of the SEP bit [1] to select the proper
- key from a DNSSEC key set; thereby reducing the chance that the wrong
- DNSKEY is sent. It can validate the self-signature over a key;
- thereby verifying the ownership of the private key material.
- Fetching the DNSKEY from the DNS ensures that the chain of trust
- remains intact once the parent publishes the DS RR indicating the
- child is secure.
-
- Note: the off-band verification is still needed when the key-material
- is fetched via the DNS. The parent can never be sure whether the
- DNSKEY RRs have been spoofed or not.
-
-4.4.2 Storing Keys or Hashes?
-
- When designing a registry system one should consider which of the
- DNSKEYs and/or the corresponding DSs to store. Since a child zone
- might wish to have a DS published using a message digest algorithm
- not yet understood by the registry, the registry can't count on being
- able to generate the DS record from a raw DNSKEY. Thus, we recommend
- that registry system at least support storing DS records.
-
- It may also be useful to store DNSKEYs, since having them may help
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 21]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- during troubleshooting and, so long as the child's chosen message
- digest is supported, the overhead of generating DS records from them
- is minimal. Having an out-of-band mechanism, such as a Whois
- database, to find out which keys are used to generate DS Resource
- Records for specific owners and/or zones may also help with
- troubleshooting.
-
- The storage considerations also relate the design of the customer
- interface and the method by which data is transfered between
- registrant and registry; Will the child zone owner be able to upload
- DS RRs with unknown hash algorithms or does the interface only allows
- DNSKEYs? In the registry-registrar model one can use the DNSSEC EPP
- protocol extensions [9] which allows transfer of DS RRs and
- optionally DNSKEY RRs.
-
-4.4.3 Security Lameness
-
- Security Lameness is defined as what happens when a parent has a DS
- RR pointing to a non-existing DNSKEY RR. During key exchange a
- parent should make sure that the child's key is actually configured
- in the DNS before publishing a DS RR in its zone. Failure to do so
- could cause the child's zone being marked as Bogus.
-
- Child zones should be very careful removing DNSKEY material,
- specifically SEP keys, for which a DS RR exists.
-
- Once a zone is "security lame", a fix (e.g. removing a DS RR) will
- take time to propagate through the DNS.
-
-4.4.4 DS Signature Validity Period
-
- Since the DS can be replayed as long as it has a valid signature, a
- short signature validity period over the DS minimizes the time a
- child is vulnerable in the case of a compromise of the child's
- KSK(s). A signature validity period that is too short introduces the
- possibility that a zone is marked Bogus in case of a configuration
- error in the signer. There may not be enough time to fix the
- problems before signatures expire. Something as mundane as operator
- unavailability during weekends shows the need for DS signature
- validity periods longer than 2 days. We recommend the minimum for a
- DS signature validity period of a few days.
-
- The maximum signature validity period of the DS record depends on how
- long child zones are willing to be vulnerable after a key compromise.
- Other considerations, such as how often the zone is (re)signed can
- also be taken into account.
-
- We consider a signature validity period of around one week to be a
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 22]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- good compromise between the operational constraints of the parent and
- minimizing damage for the child.
-
- In addition to the signature validity period, which sets a lower
- bound on the amount of times the zone owner will need to sign the
- zone data and which sets an upper bound to the time a child is
- vulnerable after key compromise, there is the TTL value on the DS
- RRs. By lowering the TTL, the authoritative servers will see more
- queries, on the other hand a low TTL increases the speed with which
- new DS RRs propagate through the DNS. As argued in Section 4.1.1,
- the TTL should be a fraction of the signature validity period.
-
-5. Security Considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- the operational considerations to maintain a stable and secure DNSSEC
- service. Not taking into account the 'data propagation' properties
- in the DNS will cause validation failures and may make secured zones
- unavailable to security aware resolvers.
-
-6. Acknowledgments
-
- Most of the ideas in this draft were the result of collective efforts
- during workshops, discussions and try outs.
-
- At the risk of forgetting individuals who were the original
- contributors of the ideas we would like to acknowledge people who
- were actively involved in the compilation of this document. In
- random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
- Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
- Olivier Courtay, Sam Weiler, Jelte Jansen and Niall O'Reilly.
-
- Some material in this document has been shamelessly copied from
- RFC2541 [7] by Donald Eastlake.
-
- Mike StJohns designed the key exchange between parent and child
- mentioned in the last paragraph of Section 4.2.2
-
- Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
- Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
- the spelling and style issues.
-
- Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-7. References
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 23]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-7.1 Normative References
-
- [1] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
- (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
- RFC 3757, May 2004.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
-7.2 Informative References
-
- [3] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [5] Eastlake, D., "Secure Domain Name System Dynamic Update",
- RFC 2137, April 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
- [7] Eastlake, D., "DNS Security Operational Considerations",
- RFC 2541, March 1999.
-
- [8] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
- RFC 3658, December 2003.
-
- [9] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
- Mapping for the Extensible Provisioning Protocol (EPP)",
- draft-hollenbeck-epp-secdns-07 (work in progress), March 2005.
-
- [10] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
- Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
- [11] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
- Source Code in C", 1996.
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 24]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- The Netherlands
-
- Phone: +31 20 535 4444
- Email: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Miek Gieben
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- The Netherlands
-
- Email: miek@nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-Appendix A. Terminology
-
- In this document there is some jargon used that is defined in other
- documents. In most cases we have not copied the text from the
- documents defining the terms but given a more elaborate explanation
- of the meaning. Note that these explanations should not be seen as
- authoritative.
-
- Anchored Key: A DNSKEY configured in resolvers around the globe.
- This key is hard to update, hence the term anchored.
- Bogus: Also see Section 5 of [2]. An RRset in DNSSEC is marked
- "Bogus" when a signature of a RRset does not validate against a
- DNSKEY.
- Key-Signing Key or KSK: A Key-Signing Key (KSK) is a key that is used
- exclusively for signing the apex key set. The fact that a key is
- a KSK is only relevant to the signing tool.
- Private and Public Keys: DNSSEC secures the DNS through the use of
- public key cryptography. Public key cryptography is based on the
- existence of two keys, a public key and a private key. The public
- keys are published in the DNS by use of the DNSKEY Resource Record
- (DNSKEY RR). Private keys should remain private.
- Key Rollover: A key rollover (also called key supercession in some
- environments) is the act of replacing one key pair by another at
- the end of a key effectivity period.
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 25]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- Secure Entry Point key or SEP Key: A KSK that has a parental DS
- record pointing to it. Note: this is not enforced in the
- protocol. A SEP Key with no parental DS is security lame.
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
- Signer: The system that has access to the private key material and
- signs the Resource Record sets in a zone. A signer may be
- configured to sign only parts of the zone e.g. only those RRsets
- for which existing signatures are about to expire.
- Zone-Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
- used for signing all data in a zone. The fact that a key is a ZSK
- is only relevant to the signing tool.
- Zone Administrator: The 'role' that is responsible for signing a zone
- and publishing it on the primary authoritative server.
-
-Appendix B. Zone-signing Key Rollover Howto
-
- Using the pre-published signature scheme and the most conservative
- method to assure oneself that data does not live in caches here
- follows the "HOWTO".
- Step 0: The preparation: Create two keys and publish both in your key
- set. Mark one of the keys as "active" and the other as
- "published". Use the "active" key for signing your zone data.
- Store the private part of the "published" key, preferably off-
- line.
- The protocol does not provide for attributes to mark a key as
- active or published. This is something you have to do on your
- own, through the use of a notebook or key management tool.
- Step 1: Determine expiration: At the beginning of the rollover make a
- note of the highest expiration time of signatures in your zone
- file created with the current key marked as "active".
- Wait until the expiration time marked in Step 1 has passed
- Step 2: Then start using the key that was marked as "published" to
- sign your data i.e. mark it as "active". Stop using the key that
- was marked as "active", mark it as "rolled".
- Step 3: It is safe to engage in a new rollover (Step 1) after at
- least one "signature validity period".
-
-Appendix C. Typographic Conventions
-
- The following typographic conventions are used in this document:
- Key notation: A key is denoted by KEYx, where x is a number, x could
- be thought of as the key id.
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 26]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- RRset notations: RRs are only denoted by the type. All other
- information - owner, class, rdata and TTL - is left out. Thus:
- "example.com 3600 IN A 192.168.1.1" is reduced to "A". RRsets are
- a list of RRs. A example of this would be: "A1,A2", specifying
- the RRset containing two "A" records. This could again be
- abbreviated to just "A".
- Signature notation: Signatures are denoted as RRSIGx(RRset), which
- means that RRset is signed with DNSKEYx.
- Zone representation: Using the above notation we have simplified the
- representation of a signed zone by leaving out all unnecessary
- details such as the names and by representing all data by "SOAx"
- SOA representation: SOA's are represented as SOAx, where x is the
- serial number.
- Using this notation the following zone:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 27]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- example.net. 600 IN SOA ns.example.net. bert.example.net. (
- 10 ; serial
- 450 ; refresh (7 minutes 30 seconds)
- 600 ; retry (10 minutes)
- 345600 ; expire (4 days)
- 300 ; minimum (5 minutes)
- )
- 600 RRSIG SOA 5 2 600 20130522213204 (
- 20130422213204 14 example.net.
- cmL62SI6iAX46xGNQAdQ... )
- 600 NS a.iana-servers.net.
- 600 NS b.iana-servers.net.
- 600 RRSIG NS 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- SO5epiJei19AjXoUpFnQ ... )
- 3600 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0...
- ) ; key id = 14
- 3600 DNSKEY 256 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU...
- ) ; key id = 15
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 14 example.net.
- J4zCe8QX4tXVGjV4e1r9... )
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 15 example.net.
- keVDCOpsSeDReyV6O... )
- 600 RRSIG NSEC 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- obj3HEp1GjnmhRjX... )
- a.example.net. 600 IN TXT "A label"
- 600 RRSIG TXT 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- IkDMlRdYLmXH7QJnuF3v... )
- 600 NSEC b.example.com. TXT RRSIG NSEC
- 600 RRSIG NSEC 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following representation:
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 28]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- SOA10
- RRSIG14(SOA10)
-
- DNSKEY14
- DNSKEY15
-
- RRSIG14(KEY)
- RRSIG15(KEY)
-
- The rest of the zone data has the same signature as the SOA record,
- i.e a RRSIG created with DNSKEY 14.
-
-Appendix D. Document Details and Changes
-
- This section is to be removed by the RFC editor if and when the
- document is published.
-
- $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
- 2005/03/21 15:51:41 dnssec Exp $
-
-D.1 draft-ietf-dnsop-dnssec-operational-practices-00
-
- Submission as working group document. This document is a modified
- and updated version of draft-kolkman-dnssec-operational-practices-00.
-
-D.2 draft-ietf-dnsop-dnssec-operational-practices-01
-
- changed the definition of "Bogus" to reflect the one in the protocol
- draft.
-
- Bad to Bogus
-
- Style and spelling corrections
-
- KSK - SEP mapping made explicit.
-
- Updates from Sam Weiler added
-
-D.3 draft-ietf-dnsop-dnssec-operational-practices-02
-
- Style and errors corrected.
-
- Added Automatic rollover requirements from I-D.ietf-dnsop-key-
- rollover-requirements.
-
-D.4 draft-ietf-dnsop-dnssec-operational-practices-03
-
- Added the definition of Key effectivity period and used that term
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 29]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
- instead of Key validity period.
-
- Modified the order of the sections, based on a suggestion by Rip
- Loomis.
-
- Included parts from RFC2541 [7]. Most of its ground was already
- covered. This document obsoletes RFC2541 [7]. Section 3.1.2
- deserves some review as it in contrast to RFC2541 does _not_ give
- recomendations about root-zone keys.
-
- added a paragraph to Section 4.4.4
-
-D.5 draft-ietf-dnsop-dnssec-operational-practices-04
-
- Somewhat more details added about the pre-publish KSK rollover. Also
- moved that subsection down a bit.
-
- Editorial and content nits that came in during wg last call were
- fixed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 30]
-\f
-Internet-Draft DNSSEC Operational Practices March 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Kolkman & Gieben Expires September 2, 2005 [Page 31]
-\f
+++ /dev/null
-
-
-Network Working Group S. Woolf
-Internet-Draft Internet Systems Consortium, Inc.
-Expires: September 14, 2005 D. Conrad
- Nominum, Inc.
- March 13, 2005
-
-
- Identifying an Authoritative Name Server
- draft-ietf-dnsop-serverid-04
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 14, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-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
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 1]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
- query would be useful, particularly as a diagnostic aid. Existing ad
- hoc mechanisms for addressing this concern are not adequate. This
- document attempts to describe the common ad hoc solution to this
- problem, including its advantages and disadvantages, and to
- characterize an improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 2]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-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. A standardized mechanism to
- determine the identity of a name server responding to a particular
- query would be useful, particularly as a diagnostic aid.
-
- Unfortunately, existing ad-hoc mechanisms for providing such
- identification 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 one widely deployed implementation of the DNS
- protocol and discusses requirements for an improved solution to the
- problem.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 3]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-2. Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. However, relying on the IP address of the name server
- has become more problematic due the deployment of various load
- balancing solutions, including the use of shared unicast addresses as
- documented in [RFC3258].
-
- An unfortunate side effect of these load balancing solutions, and
- some changes in management practices as the public Internet has
- evolved, is that traditional methods of determining which server is
- responding can be unreliable. Specifically, non-DNS methods such as
- ICMP ping, TCP connections, or non-DNS UDP packets (such as those
- generated by tools such as "traceroute"), etc., can end up going to a
- different server than that 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 my query". 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 14, 2005 [Page 4]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-3. Existing Conventions
-
- Recent versions of the commonly deployed Berkeley Internet Name
- Domain implementation of the DNS protocol suite from the Internet
- Software Consortium [BIND] support a way of identifying a particular
- server via the use of a standard, if somewhat unusual, DNS query.
- Specifically, a query to a late model 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 (defaulting to the value 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.
-
- 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 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.
-
-3.1 Advantages
-
- There are several valuable attributes to this mechanism, which
- account for its usefulness.
- 1. The "hostname.bind" 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 machine 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 does not require
- any special exceptions to site security policy.
- 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.
-
-3.2 Disadvantages
-
- At the same time, there are some forbidding drawbacks to the
- VERSION.BIND mechanism that argue against standardizing it as it
- currently operates.
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 5]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
- 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. It 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.
-
- The first of the listed disadvantages is 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 14, 2005 [Page 6]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-4. 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.
- 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. The identification mechanism SHOULD NOT be
- implementation-specific.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 7]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-5. 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. Should such extensions be specified and adopted by normal
- IETF process, the specification will include appropriate guidance to
- IANA.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 8]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-6. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 9]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-7. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 10]
-\f
-Internet-Draft Identifying an Authoritative Name Server March 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Woolf & Conrad Expires September 14, 2005 [Page 11]
-\f
-
4074: Common Misbehavior Against DNS Queries for IPv6 Addresses
4159: Deprecation of "ip6.int"
4193: Unique Local IPv6 Unicast Addresses
+4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
+4343: Domain Name System (DNS) Case Insensitivity Clarification
+4367: What's in a Name: False Assumptions about DNS Names
+4431: The DNSSEC Lookaside Validation (DLV) DNS Resource Record
/*
- * Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: sshfp_44.c,v 1.3 2004/03/05 05:10:18 marka Exp $ */
+/* $Id: sshfp_44.c,v 1.3.18.1 2006/03/10 04:04:32 marka Exp $ */
-/* draft-ietf-secsh-dns-05.txt */
+/* RFC 4255 */
#ifndef RDATA_GENERIC_SSHFP_44_C
#define RDATA_GENERIC_SSHFP_44_C
/*
- * Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2006 Internet Systems Consortium, Inc. ("ISC")
* Copyright (C) 2003 Internet Software Consortium.
*
* Permission to use, copy, modify, and distribute this software for any
* PERFORMANCE OF THIS SOFTWARE.
*/
-/* $Id: sshfp_44.h,v 1.2.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: sshfp_44.h,v 1.2.18.3 2006/03/10 04:04:32 marka Exp $ */
/*!
- * \brief Per draft-ietf-secsh-dns-05.txt */
+ * \brief Per RFC 4255 */
#ifndef GENERIC_SSHFP_44_H
#define GENERIC_SSHFP_44_H 1
projects / thirdparty / bind9.git / commitdiff
