diff options
| author | dougb <dougb@FreeBSD.org> | 2006-01-14 02:11:56 +0000 |
|---|---|---|
| committer | dougb <dougb@FreeBSD.org> | 2006-01-14 02:11:56 +0000 |
| commit | 84bc3de5bbb61ae08f39b1c2e7731c0cac2209f6 (patch) | |
| tree | 732644881f260d22d6298a820f529085aed4616d /contrib/bind9/doc | |
| parent | cfe23adacb6eecdaab74e2843766753a4732a86a (diff) | |
| download | FreeBSD-src-84bc3de5bbb61ae08f39b1c2e7731c0cac2209f6.zip FreeBSD-src-84bc3de5bbb61ae08f39b1c2e7731c0cac2209f6.tar.gz | |
Remove files from the vendor branch that are no longer present
in BIND 9.3.2 that were mistakenly removed from HEAD.
Diffstat (limited to 'contrib/bind9/doc')
23 files changed, 0 insertions, 21218 deletions
diff --git a/contrib/bind9/doc/arm/isc.color.gif b/contrib/bind9/doc/arm/isc.color.gif Binary files differdeleted file mode 100644 index 09c327c..0000000 --- a/contrib/bind9/doc/arm/isc.color.gif +++ /dev/null diff --git a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in deleted file mode 100644 index 33fc938..0000000 --- a/contrib/bind9/doc/arm/nominum-docbook-html.dsl.in +++ /dev/null @@ -1,148 +0,0 @@ -<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [ -<!ENTITY dbstyle SYSTEM "@HTMLSTYLE@" CDATA DSSSL> -]> - -<style-sheet> -<style-specification use="docbook"> -<style-specification-body> - -<!-- ;; your stuff goes here... --> - -(define %html-prefix% - ;; Add the specified prefix to HTML output filenames - "Bv9ARM.") - -(define %use-id-as-filename% - ;; Use ID attributes as name for component HTML files? - #t) - -(define %root-filename% - ;; Name for the root HTML document - "Bv9ARM") - -(define %section-autolabel% - ;; REFENTRY section-autolabel - ;; PURP Are sections enumerated? - ;; DESC - ;; If true, unlabeled sections will be enumerated. - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - #t) - -(define %html-ext% - ;; REFENTRY html-ext - ;; PURP Default extension for HTML output files - ;; DESC - ;; The default extension for HTML output files. - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - ".html") - -(define nochunks - ;; REFENTRY nochunks - ;; PURP Suppress chunking of output pages - ;; DESC - ;; If true, the entire source document is formatted as a single HTML - ;; document and output on stdout. - ;; (This option can conveniently be set with '-V nochunks' on the - ;; Jade command line). - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - #f) - -(define rootchunk - ;; REFENTRY rootchunk - ;; PURP Make a chunk for the root element when nochunks is used - ;; DESC - ;; If true, a chunk will be created for the root element, even though - ;; nochunks is specified. This option has no effect if nochunks is not - ;; true. - ;; (This option can conveniently be set with '-V rootchunk' on the - ;; Jade command line). - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - #t) - -(define html-index - ;; REFENTRY html-index - ;; PURP HTML indexing? - ;; DESC - ;; Turns on HTML indexing. If true, then index data will be written - ;; to the file defined by 'html-index-filename'. This data can be - ;; collated and turned into a DocBook index with bin/collateindex.pl. - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - #t) - -(define html-manifest - ;; REFENTRY html-manifest - ;; PURP Write a manifest? - ;; DESC - ;; If not '#f' then the list of HTML files created by the stylesheet - ;; will be written to the file named by 'html-manifest-filename'. - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - #t) - -(define (chunk-element-list) - (list (normalize "preface") - (normalize "chapter") - (normalize "appendix") - (normalize "article") - (normalize "glossary") - (normalize "bibliography") - (normalize "index") - (normalize "colophon") - (normalize "setindex") - (normalize "reference") - (normalize "refentry") - (normalize "part") - (normalize "book") ;; just in case nothing else matches... - (normalize "set") ;; sets are definitely chunks... - )) - -; -; Add some cell padding to tables so that they don't look so cramped -; in Netscape. -; -; The following definition was cut-and-pasted from dbtable.dsl and the -; single line containing the word CELLPADDING was added. -; -(element tgroup - (let* ((wrapper (parent (current-node))) - (frameattr (attribute-string (normalize "frame") wrapper)) - (pgwide (attribute-string (normalize "pgwide") wrapper)) - (footnotes (select-elements (descendants (current-node)) - (normalize "footnote"))) - (border (if (equal? frameattr (normalize "none")) - '(("BORDER" "0")) - '(("BORDER" "1")))) - (width (if (equal? pgwide "1") - (list (list "WIDTH" ($table-width$))) - '())) - (head (select-elements (children (current-node)) (normalize "thead"))) - (body (select-elements (children (current-node)) (normalize "tbody"))) - (feet (select-elements (children (current-node)) (normalize "tfoot")))) - (make element gi: "TABLE" - attributes: (append - '(("CELLPADDING" "3")) - border - width - (if %cals-table-class% - (list (list "CLASS" %cals-table-class%)) - '())) - (process-node-list head) - (process-node-list body) - (process-node-list feet) - (make-table-endnotes)))) - -</style-specification-body> -</style-specification> -<external-specification id="docbook" document="dbstyle"> -</style-sheet> diff --git a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in b/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in deleted file mode 100644 index 511d6c4..0000000 --- a/contrib/bind9/doc/arm/nominum-docbook-print.dsl.in +++ /dev/null @@ -1,42 +0,0 @@ -<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [ -<!ENTITY dbstyle SYSTEM "@PRINTSTYLE@" CDATA DSSSL> -]> - - -<style-sheet> -<style-specification use="docbook"> -<style-specification-body> - -<!-- ;; your stuff goes here... --> - -(define %generate-book-titlepage% #t) - -(define %section-autolabel% - ;; REFENTRY section-autolabel - ;; PURP Are sections enumerated? - ;; DESC - ;; If true, unlabeled sections will be enumerated. - ;; /DESC - ;; AUTHOR N/A - ;; /REFENTRY - #t) - -;; Margins around cell contents -;; (define %cals-cell-before-row-margin% 20pt) -;; (define %cals-cell-after-row-margin% 20pt) - -;; seems to be a bug in JadeTeX -- we get a wierd indent on table -;; cells for the first line only. This is a workaround. -;; Adam Di Carlo, adam@onshore.com -(define %cals-cell-before-column-margin% 5pt) -(define %cals-cell-after-column-margin% 5pt) - -;; Inheritable start and end indent for cell contents -(define %cals-cell-content-start-indent% 5pt) -(define %cals-cell-content-end-indent% 5pt) - - -</style-specification-body> -</style-specification> -<external-specification id="docbook" document="dbstyle"> -</style-sheet> diff --git a/contrib/bind9/doc/arm/validate.sh.in b/contrib/bind9/doc/arm/validate.sh.in deleted file mode 100644 index f50d8a0..0000000 --- a/contrib/bind9/doc/arm/validate.sh.in +++ /dev/null @@ -1,21 +0,0 @@ -#!/bin/sh -# -# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") -# Copyright (C) 2000, 2001 Internet Software Consortium. -# -# Permission to use, copy, modify, and distribute this software for any -# purpose with or without fee is hereby granted, provided that the above -# copyright notice and this permission notice appear in all copies. -# -# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH -# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, -# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -# PERFORMANCE OF THIS SOFTWARE. - -# $Id: validate.sh.in,v 1.2.206.1 2004/03/06 13:16:14 marka Exp $ - -nsgmls -sv @SGMLDIR@/docbook/dsssl/modular/dtds/decls/xml.dcl \ - Bv9ARM-book.xml diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt deleted file mode 100644 index 0977661..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt +++ /dev/null @@ -1,561 +0,0 @@ - - -DNSEXT M. Stapp -Internet-Draft Cisco Systems, Inc. -Expires: January 14, 2005 T. Lemon - A. Gustafsson - Nominum, Inc. - July 16, 2004 - - - A DNS RR for Encoding DHCP Information (DHCID RR) - <draft-ietf-dnsext-dhcid-rr-08.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 January 14, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -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] - proposes storing client identifiers in the DNS to unambiguously - - - -Stapp, et al. Expires January 14, 2005 [Page 1] - -Internet-Draft The DHCID RR July 2004 - - - 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 January 14, 2005 [Page 2] - -Internet-Draft The DHCID RR July 2004 - - -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 January 14, 2005 [Page 3] - -Internet-Draft The DHCID RR July 2004 - - -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 January 14, 2005 [Page 4] - -Internet-Draft The DHCID RR July 2004 - - - 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 January 14, 2005 [Page 5] - -Internet-Draft The DHCID RR July 2004 - - -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 January 14, 2005 [Page 6] - -Internet-Draft The DHCID RR July 2004 - - - 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 January 14, 2005 [Page 7] - -Internet-Draft The DHCID RR July 2004 - - -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 January 14, 2005 [Page 8] - -Internet-Draft The DHCID RR July 2004 - - -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 January 14, 2005 [Page 9] - -Internet-Draft The DHCID RR July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Stapp, et al. Expires January 14, 2005 [Page 10] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt deleted file mode 100644 index 0783e7b..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt +++ /dev/null @@ -1,1457 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: January 13, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - July 15, 2004 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-11 - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I 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 January 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - The Domain Name System Security Extensions (DNSSEC) add data origin - authentication and data integrity to the Domain Name System. This - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - document introduces these extensions, and describes their - capabilities and limitations. This document also discusses the - services that the DNS security extensions do and do not provide. - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 - 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 - 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 - 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 - 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 - 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 - 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 - 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 - 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . 26 - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents - ([I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the - security extensions defined in RFC 2535 [RFC2535] and its - predecessors. These security extensions consist of a set of new - resource record types and modifications to the existing DNS protocol - [RFC1035]. The new records and protocol modifications are not fully - described in this document, but are described in a family of - documents outlined in Section 10. Section 3 and Section 4 describe - the capabilities and limitations of the security extensions in - greater detail. Section 5 discusses the scope of the document set. - Section 6, Section 7, Section 8, and Section 9 discuss the effect - that these security extensions will have on resolvers, stub - resolvers, zones and name servers. - - This document and its two companions update and obsolete RFCs 2535 - [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 - [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress - [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but - does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 - [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts - of 3226 [RFC3226] (dealing with DNSSEC). - - The DNS security extensions provide origin authentication and - integrity protection for DNS data, as well as a means of public key - distribution. These extensions do not provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -2. Definitions of Important DNSSEC Terms - - This section defines a number of terms used in this document set. - Since this is intended to be useful as a reference while reading the - rest of the document set, first-time readers may wish to skim this - section quickly, read the rest of this document, then come back to - this section. - - Authentication Chain: An alternating sequence of DNSKEY RRsets and DS - RRsets forms a chain of signed data, with each link in the chain - vouching for the next. A DNSKEY RR is used to verify the - signature covering a DS RR and allows the DS RR to be - authenticated. The DS RR contains a hash of another DNSKEY RR and - this new DNSKEY RR is authenticated by matching the hash in the DS - RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset - and, in turn, some DNSKEY RR in this set may be used to - authenticate another DS RR and so forth until the chain finally - ends with a DNSKEY RR whose corresponding private key signs the - desired DNS data. For example, the root DNSKEY RRset can be used - to authenticate the DS RRset for "example." The "example." DS - RRset contains a hash that matches some "example." DNSKEY, and - this DNSKEY's corresponding private key signs the "example." - DNSKEY RRset. Private key counterparts of the "example." DNSKEY - RRset sign data records such as "www.example." as well as DS RRs - for delegations such as "subzone.example." - - Authentication Key: A public key that a security-aware resolver has - verified and can therefore use to authenticate data. A - security-aware resolver can obtain authentication keys in three - ways. First, the resolver is generally configured to know about - at least one public key; this configured data is usually either - the public key itself or a hash of the public key as found in the - DS RR (see "trust anchor"). Second, the resolver may use an - authenticated public key to verify a DS RR and the DNSKEY RR to - which the DS RR refers. Third, the resolver may be able to - determine that a new public key has been signed by the private key - corresponding to another public key which the resolver has - verified. Note that the resolver must always be guided by local - policy when deciding whether to authenticate a new public key, - even if the local policy is simply to authenticate any new public - key for which the resolver is able verify the signature. - - Delegation Point: Term used to describe the name at the parental side - of a zone cut. That is, the delegation point for "foo.example" - would be the foo.example node in the "example" zone (as opposed to - the zone apex of the "foo.example" zone). - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - Island of Security: Term used to describe a signed, delegated zone - that does not have an authentication chain from its delegating - parent. That is, there is no DS RR containing a hash of a DNSKEY - RR for the island in its delegating parent zone (see - [I-D.ietf-dnsext-dnssec-records]). An island of security is - served by security-aware name servers and may provide - authentication chains to any delegated child zones. Responses - from an island of security or its descendents can only be - authenticated if its authentication keys can be authenticated by - some trusted means out of band from the DNS protocol. - - Key Signing Key (KSK): An authentication key that corresponds to a - private key used to sign one or more other authentication keys for - a given zone. Typically, the private key corresponding to a key - signing key will sign a zone signing key, which in turn has a - corresponding private key which will sign other zone data. Local - policy may require the zone signing key to be changed frequently, - while the key signing key may have a longer validity period in - order to provide a more stable secure entry point into the zone. - Designating an authentication key as a key signing key is purely - an operational issue: DNSSEC validation does not distinguish - between key signing keys and other DNSSEC authentication keys, and - it is possible to use a single key as both a key signing key and a - zone signing key. Key signing keys are discussed in more detail - in [RFC3757]. Also see: zone signing key. - - Non-Validating Security-Aware Stub Resolver: A security-aware stub - resolver which trusts one or more security-aware recursive name - servers to perform most of the tasks discussed in this document - set on its behalf. In particular, a non-validating security-aware - stub resolver is an entity which sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. See also: security-aware stub resolver, validating - security-aware stub resolver. - - Non-Validating Stub Resolver: A less tedious term for a - non-validating security-aware stub resolver. - - Security-Aware Name Server: An entity acting in the role of a name - server (defined in section 2.4 of [RFC1034]) that understands the - DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity which - receives DNS queries, sends DNS responses, supports the EDNS0 - [RFC2671] message size extension and the DO bit [RFC3225], and - supports the RR types and message header bits defined in this - document set. - - - -Arends, et al. Expires January 13, 2005 [Page 5] - - - Security-Aware Recursive Name Server: An entity which acts in both - the security-aware name server and security-aware resolver roles. - A more cumbersome equivalent phrase would be "a security-aware - name server which offers recursive service". - - Security-Aware Resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) which understands the DNS - security extensions defined in this document set. In particular, - a security-aware resolver is an entity which sends DNS queries, - receives DNS responses, supports the EDNS0 [RFC2671] message size - extension and the DO bit [RFC3225], and is capable of using the RR - types and message header bits defined in this document set to - provide DNSSEC services. - - Security-Aware Stub Resolver: An entity acting in the role of a stub - resolver (defined in section 5.3.1 of [RFC1034]) which has enough - of an understanding the DNS security extensions defined in this - document set to provide additional services not available from a - security-oblivious stub resolver. Security-aware stub resolvers - may be either "validating" or "non-validating" depending on - whether the stub resolver attempts to verify DNSSEC signatures on - its own or trusts a friendly security-aware name server to do so. - See also: validating stub resolver, non-validating stub resolver. - - Security-Oblivious <anything>: An <anything> that is not - "security-aware". - - Signed Zone: A zone whose RRsets are signed and which contains - properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS - records. - - Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A - validating security-aware resolver uses this public key or hash as - a starting point for building the authentication chain to a signed - DNS response. In general, a validating resolver will need to - obtain the initial values of its trust anchors via some secure or - trusted means outside the DNS protocol. Presence of a trust - anchor also implies that the resolver should expect the zone to - which the trust anchor points to be signed. - - Unsigned Zone: A zone that is not signed. - - Validating Security-Aware Stub Resolver: A security-aware resolver - that sends queries in recursive mode but which performs signature - validation on its own rather than just blindly trusting an - upstream security-aware recursive name server. See also: - security-aware stub resolver, non-validating security-aware stub - resolver. - - - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - Validating Stub Resolver: A less tedious term for a validating - security-aware stub resolver. - - Zone Signing Key (ZSK): An authentication key that corresponds to a - private key used to sign a zone. Typically a zone signing key - will be part of the same DNSKEY RRset as the key signing key whose - corresponding private key signs this DNSKEY RRset, but the zone - signing key is used for a slightly different purpose, and may - differ from the key signing key in other ways, such as validity - lifetime. Designating an authentication key as a zone signing key - is purely an operational issue: DNSSEC validation does not - distinguish between zone signing keys and other DNSSEC - authentication keys, and it is possible to use a single key as - both a key signing key and a zone signing key. See also: key - signing key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) security extensions provide origin - authentication and integrity assurance services for DNS data, - including mechanisms for authenticated denial of existence of DNS - data. These mechanisms are described below. - - These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two - new message header bits (CD and AD). In order to support the larger - DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also - requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support - for the DO bit [RFC3225], so that a security-aware resolver can - indicate in its queries that it wishes to receive DNSSEC RRs in - response messages. - - These services protect against most of the threats to the Domain Name - System described in [I-D.ietf-dnsext-dns-threats]. - -3.1 Data Origin Authentication and Data Integrity - - DNSSEC provides authentication by associating cryptographically - generated digital signatures with DNS RRsets. These digital - signatures are stored in a new resource record, the RRSIG record. - Typically, there will be a single private key that signs a zone's - data, but multiple keys are possible: for example, there may be keys - for each of several different digital signature algorithms. If a - security-aware resolver reliably learns a zone's public key, it can - authenticate that zone's signed data. An important DNSSEC concept is - that the key that signs a zone's data is associated with the zone - itself and not with the zone's authoritative name servers (public - keys for DNS transaction authentication mechanisms may also appear in - zones, as described in [RFC2931], but DNSSEC itself is concerned with - object security of DNS data, not channel security of DNS - transactions. The keys associated with transaction security may be - stored in different RR types. See [RFC3755] for details.). - - A security-aware resolver can learn a zone's public key either by - having a trust anchor configured into the resolver or by normal DNS - resolution. To allow the latter, public keys are stored in a new - type of resource record, the DNSKEY RR. Note that the private keys - used to sign zone data must be kept secure, and should be stored - offline when practical to do so. To discover a public key reliably - via DNS resolution, the target key itself needs to be signed by - either a configured authentication key or another key that has been - authenticated previously. Security-aware resolvers authenticate zone - information by forming an authentication chain from a newly learned - public key back to a previously known authentication public key, - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - which in turn either has been configured into the resolver or must - have been learned and verified previously. Therefore, the resolver - must be configured with at least one trust anchor. If the configured - key is a zone signing key, then it will authenticate the associated - zone; if the configured key is a key signing key, it will - authenticate a zone signing key. If the resolver has been configured - with the hash of a key rather than the key itself, the resolver may - need to obtain the key via a DNS query. To help security-aware - resolvers establish this authentication chain, security-aware name - servers attempt to send the signature(s) needed to authenticate a - zone's public key(s) in the DNS reply message along with the public - key itself, provided there is space available in the message. - - The Delegation Signer (DS) RR type simplifies some of the - administrative tasks involved in signing delegations across - organizational boundaries. The DS RRset resides at a delegation - point in a parent zone and indicates the public key(s) corresponding - to the private key(s) used to self-sign the DNSKEY RRset at the - delegated child zone's apex. The administrator of the child zone, in - turn, uses the private key(s) corresponding to one or more of the - public keys in this DNSKEY RRset to sign the child zone's data. The - typical authentication chain is therefore - DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more - DS->DNSKEY subchains. DNSSEC permits more complex authentication - chains, such as additional layers of DNSKEY RRs signing other DNSKEY - RRs within a zone. - - A security-aware resolver normally constructs this authentication - chain from the root of the DNS hierarchy down to the leaf zones based - on configured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to use one - or more configured public keys (or hashes of public keys) other than - the root public key, or may not provide configured knowledge of the - root public key, or may prevent the resolver from using particular - public keys for arbitrary reasons even if those public keys are - properly signed with verifiable signatures. DNSSEC provides - mechanisms by which a security-aware resolver can determine whether - an RRset's signature is "valid" within the meaning of DNSSEC. In the - final analysis however, authenticating both DNS keys and data is a - matter of local policy, which may extend or even override the - protocol extensions defined in this document set. See Section 5 for - further discussion. - -3.2 Authenticating Name and Type Non-Existence - - The security mechanism described in Section 3.1 only provides a way - to sign existing RRsets in a zone. The problem of providing negative - responses with the same level of authentication and integrity - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - requires the use of another new resource record type, the NSEC - record. The NSEC record allows a security-aware resolver to - authenticate a negative reply for either name or type non-existence - via the same mechanisms used to authenticate other DNS replies. Use - of NSEC records requires a canonical representation and ordering for - domain names in zones. Chains of NSEC records explicitly describe - the gaps, or "empty space", between domain names in a zone, as well - as listing the types of RRsets present at existing names. Each NSEC - record is signed and authenticated using the mechanisms described in - Section 3.1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -4. Services Not Provided by DNS Security - - DNS was originally designed with the assumptions that the DNS will - return the same answer to any given query regardless of who may have - issued the query, and that all data in the DNS is thus visible. - Accordingly, DNSSEC is not designed to provide confidentiality, - access control lists, or other means of differentiating between - inquirers. - - DNSSEC provides no protection against denial of service attacks. - Security-aware resolvers and security-aware name servers are - vulnerable to an additional class of denial of service attacks based - on cryptographic operations. Please see Section 12 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above are not designed to - protect operations such as zone transfers and dynamic update - [RFC3007]. Message authentication schemes described in [RFC2845] and - [RFC2931] address security operations that pertain to these - transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -5. Scope of the DNSSEC Document Set and Last Hop Issues - - The specification in this document set defines the behavior for zone - signers and security-aware name servers and resolvers in such a way - that the validating entities can unambiguously determine the state of - the data. - - A validating resolver can determine these 4 states: - - Secure: The validating resolver has a trust anchor, a chain of trust - and is able to verify all the signatures in the response. - - Insecure: The validating resolver has a trust anchor, a chain of - trust, and, at some delegation point, signed proof of the - non-existence of a DS record. That indicates that subsequent - branches in the tree are provably insecure. A validating resolver - may have local policy to mark parts of the domain space as - insecure. - - Bogus: The validating resolver has a trust anchor and there is a - secure delegation which is indicating that subsidiary data will be - signed, but the response fails to validate due to one or more - reasons: missing signatures, expired signatures, signatures with - unsupported algorithms, data missing which the relevant NSEC RR - says should be present, and so forth. - - Indeterminate: There is no trust anchor which would indicate that a - specific portion of the tree is secure. This is the default - operation mode. - - This specification only defines how security aware name servers can - signal non-validating stub resolvers that data was found to be bogus - (using RCODE=2, "Server Failure" -- see - [I-D.ietf-dnsext-dnssec-protocol]). - - There is a mechanism for security aware name servers to signal - security-aware stub resolvers that data was found to be secure (using - the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). - - This specification does not define a format for communicating why - responses were found to be bogus or marked as insecure. The current - signaling mechanism does not distinguish between indeterminate and - insecure. - - A method for signaling advanced error codes and policy between a - security aware stub resolver and security aware recursive nameservers - is a topic for future work, as is the interface between a security - aware resolver and the applications that use it. Note, however, that - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - the lack of the specification of such communication does not prohibit - deployment of signed zones or the deployment of security aware - recursive name servers that prohibit propagation of bogus data to the - applications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -6. Resolver Considerations - - A security-aware resolver needs to be able to perform cryptographic - functions necessary to verify digital signatures using at least the - mandatory-to-implement algorithm(s). Security-aware resolvers must - also be capable of forming an authentication chain from a newly - learned zone back to an authentication key, as described above. This - process might require additional queries to intermediate DNS zones to - obtain necessary DNSKEY, DS and RRSIG records. A security-aware - resolver should be configured with at least one trust anchor as the - starting point from which it will attempt to establish authentication - chains. - - If a security-aware resolver is separated from the relevant - authoritative name servers by a recursive name server or by any sort - of device which acts as a proxy for DNS, and if the recursive name - server or proxy is not security-aware, the security-aware resolver - may not be capable of operating in a secure mode. For example, if a - security-aware resolver's packets are routed through a network - address translation device that includes a DNS proxy which is not - security-aware, the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. - - If a security-aware resolver must rely on an unsigned zone or a name - server that is not security aware, the resolver may not be able to - validate DNS responses, and will need a local policy on whether to - accept unverified responses. - - A security-aware resolver should take a signature's validation period - into consideration when determining the TTL of data in its cache, to - avoid caching signed data beyond the validity period of the - signature, but should also allow for the possibility that the - security-aware resolver's own clock is wrong. Thus, a security-aware - resolver which is part of a security-aware recursive name server will - need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid - blocking valid signatures from getting through to other - security-aware resolvers which are clients of this recursive name - server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure - recursive server handles queries with the CD bit set. - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -7. Stub Resolver Considerations - - Although not strictly required to do so by the protocol, most DNS - queries originate from stub resolvers. Stub resolvers, by - definition, are minimal DNS resolvers which use recursive query mode - to offload most of the work of DNS resolution to a recursive name - server. Given the widespread use of stub resolvers, the DNSSEC - architecture has to take stub resolvers into account, but the - security features needed in a stub resolver differ in some respects - from those needed in a full security-aware resolver. - - Even a security-oblivious stub resolver may get some benefit from - DNSSEC if the recursive name servers it uses are security-aware, but - for the stub resolver to place any real reliance on DNSSEC services, - the stub resolver must trust both the recursive name servers in - question and the communication channels between itself and those name - servers. The first of these issues is a local policy issue: in - essence, a security-oblivious stub resolver has no real choice but to - place itself at the mercy of the recursive name servers that it uses, - since it does not perform DNSSEC validity checks on its own. The - second issue requires some kind of channel security mechanism; proper - use of DNS transaction authentication mechanisms such as SIG(0) or - TSIG would suffice, as would appropriate use of IPsec, and particular - implementations may have other choices available, such as operating - system specific interprocess communication mechanisms. - Confidentiality is not needed for this channel, but data integrity - and message authentication are. - - A security-aware stub resolver that does trust both its recursive - name servers and its communication channel to them may choose to - examine the setting of the AD bit in the message header of the - response messages it receives. The stub resolver can use this flag - bit as a hint to find out whether the recursive name server was able - to validate signatures for all of the data in the Answer and - Authority sections of the response. - - There is one more step that a security-aware stub resolver can take - if, for whatever reason, it is not able to establish a useful trust - relationship with the recursive name servers which it uses: it can - perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. A validating stub resolver - is thus able to treat the DNSSEC signatures as a trust relationship - between the zone administrator and the stub resolver itself. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -8. Zone Considerations - - There are several differences between signed and unsigned zones. A - signed zone will contain additional security-related records (RRSIG, - DNSKEY, DS and NSEC records). RRSIG and NSEC records may be - generated by a signing process prior to serving the zone. The RRSIG - records that accompany zone data have defined inception and - expiration times, which establish a validity period for the - signatures and the zone data the signatures cover. - -8.1 TTL values vs. RRSIG validity period - - It is important to note the distinction between a RRset's TTL value - and the signature validity period specified by the RRSIG RR covering - that RRset. DNSSEC does not change the definition or function of the - TTL value, which is intended to maintain database coherency in - caches. A caching resolver purges RRsets from its cache no later - than the end of the time period specified by the TTL fields of those - RRsets, regardless of whether or not the resolver is security-aware. - - The inception and expiration fields in the RRSIG RR - [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time - period during which the signature can be used to validate the covered - RRset. The signatures associated with signed zone data are only - valid for the time period specified by these fields in the RRSIG RRs - in question. TTL values cannot extend the validity period of signed - RRsets in a resolver's cache, but 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 of the signed RRset and - its associated RRSIG RR in the resolver's cache. - -8.2 New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency which did not - exist in the original DNS protocol. A signed zone requires regular - maintenance to ensure that each RRset in the zone has a current valid - RRSIG RR. The signature validity period of an RRSIG RR is an - interval during which the signature for one particular signed RRset - can be considered valid, and the signatures of different RRsets in a - zone may expire at different times. Re-signing one or more RRsets in - a zone will change one or more RRSIG RRs, which in turn will require - incrementing the zone's SOA serial number to indicate that a zone - change has occurred and re-signing the SOA RRset itself. Thus, - re-signing any RRset in a zone may also trigger DNS NOTIFY messages - and zone transfers operations. - - - - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -9. Name Server Considerations - - A security-aware name server should include the appropriate DNSSEC - records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from - resolvers which have signaled their willingness to receive such - records via use of the DO bit in the EDNS header, subject to message - size limitations. Since inclusion of these DNSSEC RRs could easily - cause UDP message truncation and fallback to TCP, a security-aware - name server must also support the EDNS "sender's UDP payload" - mechanism. - - If possible, the private half of each DNSSEC key pair should be kept - offline, but this will not be possible for a zone for which DNS - dynamic update has been enabled. In the dynamic update case, the - primary master server for the zone will have to re-sign the zone when - updated, so the private key corresponding to the zone signing key - will have to be kept online. This is an example of a situation where - the ability to separate the zone's DNSKEY RRset into zone signing - key(s) and key signing key(s) may be useful, since the key signing - key(s) in such a case can still be kept offline and may have a longer - useful lifetime than the zone signing key(s). - - DNSSEC, by itself, is not enough to protect the integrity of an - entire zone during zone transfer operations, since even a signed zone - contains some unsigned, nonauthoritative data if the zone has any - children. Therefore, zone maintenance operations will require some - additional mechanisms (most likely some form of channel security, - such as TSIG, SIG(0), or IPsec). - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -10. DNS Security Document Family - - The DNSSEC document set can be partitioned into several main groups, - under the larger umbrella of the DNS base protocol documents. - - The "DNSSEC protocol document set" refers to the three documents - which form the core of the DNS security extensions: - 1. DNS Security Introduction and Requirements (this document) - 2. Resource Records for DNS Security Extensions - [I-D.ietf-dnsext-dnssec-records] - 3. Protocol Modifications for the DNS Security Extensions - [I-D.ietf-dnsext-dnssec-protocol] - - Additionally, any document that would add to, or change the core DNS - Security extensions would fall into this category. This includes any - future work on the communication between security-aware stub - resolvers and upstream security-aware recursive name servers. - - The "Digital Signature Algorithm Specification" document set refers - to the group of documents that describe how specific digital - signature algorithms should be implemented to fit the DNSSEC resource - record format. Each document in this set deals with a specific - digital signature algorithm. - - The "Transaction Authentication Protocol" document set refers to the - group of documents that deal with DNS message authentication, - including secret key establishment and verification. While not - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted because of its relationship to DNSSEC. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. DNSSEC does not provide any direct security for - these new uses, but may be used to support them. Documents that fall - in this category include the use of DNS in the storage and - distribution of certificates [RFC2538]. - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -11. IANA Considerations - - This overview document introduces no new IANA considerations. Please - see [I-D.ietf-dnsext-dnssec-records] for a complete review of the - IANA considerations introduced by DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -12. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets.This document discusses the capabilities and - limitations of these extensions. - - In order for a security-aware resolver to validate a DNS response, - all zones along the path from the trusted starting point to the zone - containing the response zones must be signed, and all name servers - and resolvers involved in the resolution process must be - security-aware, as defined in this document set. A security-aware - resolver cannot verify responses originating from an unsigned zone, - from a zone not served by a security-aware name server, or for any - DNS data which the resolver is only able to obtain through a - recursive name server which is not security-aware. If there is a - break in the authentication chain such that a security-aware resolver - cannot obtain and validate the authentication keys it needs, then the - security-aware resolver cannot validate the affected DNS data. - - This document briefly discusses other methods of adding security to a - DNS query, such as using a channel secured by IPsec or using a DNS - transaction authentication mechanism, but transaction security is not - part of DNSSEC per se. - - A non-validating security-aware stub resolver, by definition, does - not perform DNSSEC signature validation on its own, and thus is - vulnerable both to attacks on (and by) the security-aware recursive - name servers which perform these checks on its behalf and also to - attacks on its communication with those security-aware recursive name - servers. Non-validating security-aware stub resolvers should use - some form of channel security to defend against the latter threat. - The only known defense against the former threat would be for the - security-aware stub resolver to perform its own signature validation, - at which point, again by definition, it would no longer be a - non-validating security-aware stub resolver. - - DNSSEC does not protect against denial of service attacks. DNSSEC - makes DNS vulnerable to a new class of denial of service attacks - based on cryptographic operations against security-aware resolvers - and security-aware name servers, since an attacker can attempt to use - DNSSEC mechanisms to consume a victim's resources. This class of - attacks takes at least two forms. An attacker may be able to consume - resources in a security-aware resolver's signature validation code by - tampering with RRSIG RRs in response messages or by constructing - needlessly complex signature chains. An attacker may also be able to - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - consume resources in a security-aware name server which supports DNS - dynamic update, by sending a stream of update messages that force the - security-aware name server to re-sign some RRsets in the zone more - frequently than would otherwise be necessary. - - DNSSEC does not provide confidentiality, due to a deliberate design - choice. - - DNSSEC introduces the ability for a hostile party to enumerate all - the names in a zone by following the NSEC chain. NSEC RRs assert - which names do not exist in a zone by linking from existing name to - existing name along a canonical ordering of all the names within a - zone. Thus, an attacker can query these NSEC RRs in sequence to - obtain all the names in a zone. While not an attack on the DNS - itself, this could allow an attacker to map network hosts or other - resources by enumerating the contents of a zone. - - DNSSEC introduces significant additional complexity to the DNS, and - thus introduces many new opportunities for implementation bugs and - misconfigured zones. In particular, enabling DNSSEC signature - validation in a resolver may cause entire legitimate zones to become - effectively unreachable due to DNSSEC configuration errors or bugs. - - DNSSEC does not protect against tampering with unsigned zone data. - Non-authoritative data at zone cuts (glue and NS RRs in the parent - zone) are not signed. This does not pose a problem when validating - the authentication chain, but does mean that the non-authoritative - data itself is vulnerable to tampering during zone transfer - operations. Thus, while DNSSEC can provide data origin - authentication and data integrity for RRsets, it cannot do so for - zones, and other mechanisms must be used to protect zone transfer - operations. - - Please see [I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations. - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 21] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -13. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group. While explicitly listing everyone - who has contributed during the decade during which DNSSEC has been - under development would be an impossible task, the editors would - particularly like to thank the following people for their - contributions to and comments on this document set: Jaap Akkerhuis, - Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, - David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald - Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, - Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip - Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, - Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon - Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, - Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, - Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ - Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, - Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob - Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and - Suzanne Woolf. - - No doubt the above list is incomplete. We apologize to anyone we - left out. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -14. References - -14.1 Normative References - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in - progress), May 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-08 (work in progress), - May 2004. - - [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. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - -14.2 Informative References - - [I-D.ietf-dnsext-dns-threats] - Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-07 (work in - progress), April 2004. - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - 2004. - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - [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. - - [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in - the Domain Name System (DNS)", RFC 2538, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. - - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 24] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - -Arends, et al. Expires January 13, 2005 [Page 25] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 13, 2005 [Page 26] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt deleted file mode 100644 index 5728b35..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt +++ /dev/null @@ -1,3193 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: January 13, 2005 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - July 15, 2004 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-07 - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I 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 January 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents which describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 - 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 - 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.2 Signature Verification Support . . . . . . . . . . . . . . 19 - 4.3 Determining Security Status of Data . . . . . . . . . . . 20 - 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 - 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 - 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 - 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 - 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 - 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 - 5.1 Special Considerations for Islands of Security . . . . . . 26 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 - 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 - 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . . 57 - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document - defines the concept of a signed zone and lists the requirements for - zone signing. Section 3 describes the modifications to authoritative - name server behavior necessary to handle signed zones. Section 4 - describes the behavior of entities which include security-aware - resolver functions. Finally, Section 5 defines how to use DNSSEC RRs - to authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034] and [RFC1035]. - - This document is part of a family of documents that define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be - familiar with this document. A definition of the DNSSEC resource - records can be found in [I-D.ietf-dnsext-dnssec-records]. - -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]. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as a CNAME RR. - - DNSSEC specifies the placement of two new RR types, NSEC and DS, - which can be placed at the parental side of a zone cut (that is, at a - delegation point). This is an exception to the general prohibition - against putting data in the parent zone at a zone cut. Section 2.6 - describes this change. - -2.1 Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR - containing the corresponding public key. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set -- see Section - 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated - with other DNS operations MAY be stored in DNSKEY RRs that are not - marked as zone keys but MUST NOT be used to verify RRSIGs. - - If the zone administrator intends a signed zone to be usable other - than as an island of security, the zone apex MUST contain at least - one DNSKEY RR to act as a secure entry point into the zone. This - secure entry point could then be used as the target of a secure - delegation via a corresponding DS RR in the parent zone (see - [I-D.ietf-dnsext-dnssec-records]). - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets all of the following requirements: - o The RRSIG owner name is equal to the RRset owner name; - o The RRSIG class is equal to the RRset class; - o The RRSIG Type Covered field is equal to the RRset type; - o The RRSIG Original TTL field is equal to the TTL of the RRset; - o The RRSIG RR's TTL is equal to the TTL of the RRset; - o The RRSIG Labels field is equal to the number of labels in the - RRset owner name, not counting the null root label and not - - - -Arends, et al. Expires January 13, 2005 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - counting the leftmost label if it is a wildcard; - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - The process for constructing the RRSIG RR for a given RRset is - described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated - with delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset - located at the delegating parent (if any). - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone which has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - format of NSEC RRs and the process for constructing the NSEC RR for a - given name is described in [I-D.ietf-dnsext-dnssec-records]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner names nodes which were - not the owner name of any RRset before the zone was signed. The main - reasons for this are a desire for namespace consistency between - signed and unsigned versions of the same zone and a desire to reduce - the risk of response inconsistency in security oblivious recursive - name servers. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - The difference between the set of owner names that require RRSIG - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part is - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - - The bitmap for the NSEC 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. - -2.4 Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (that is, the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5 Changes to the CNAME Resource Record. - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - -2.6 DNSSEC RR Types Appearing at Zone Cuts. - - DNSSEC introduced two new RR types that are unusual in that they can - appear at the parental side of a zone cut. At the parental side of a - zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at - the owner name. A DS RR could also be present if the zone being - delegated is signed and wishes to have a chain of authentication to - the parent zone. This is an exception to the original DNS - specification ([RFC1034]) which states that only NS RRsets could - appear at the parental side of a zone cut. - - This specification updates the original DNS specification to allow - NSEC and DS RR types at the parent side of a zone cut. These RRsets - are authoritative for the parent when they appear at the parent side - of a zone cut. - -2.7 Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements. Functions specific to security-aware recursive name - servers are described in Section 3.2; functions specific to - authoritative servers are described in Section 3.1. - - The terms "SNAME", "SCLASS", and "STYPE" in the following discussion - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. - - A security-aware name server which receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit clear MUST - treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset, - and MUST NOT perform any of the additional processing described - below. Since the DS RR type has the peculiar property of only - existing in the parent zone at delegation points, DS RRs always - require some special processing, as described in Section 3.1.4.1. - - Security aware name servers that receive explicit queries for - security RR types which match the content of more than one zone that - it serves (for example, NSEC and RRSIG RRs above and below a - delegation point where the server is authoritative for both zones) - should behave self-consistently. The name server MAY return one of - the following: - o The above-delegation RRsets - o The below-delegation RRsets - o Both above and below-delegation RRsets - o Empty answer section (no records) - o Some other response - o An error - As long as the response is always consistent for each query to the - name server. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Section 3.1.6, - Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details - on the behavior of these bits. - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - A security aware name server which synthesizes CNAME RRs from DNAME - RRs as described in [RFC2672] SHOULD NOT generate signatures for the - synthesized CNAME RRs. - -3.1 Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name - server for a signed zone MUST include additional RRSIG, NSEC, and DS - RRs according to the following rules: - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1; - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3; - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - These rules only apply to responses the semantics of which convey - information about the presence or absence of resource records. That - is, these rules are not intended to rule out responses such as RCODE - 4 ("Not Implemented") or RCODE 5 ("Refused"). - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1 Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server SHOULD attempt to send RRSIG RRs that a - security-aware resolver can use to authenticate the RRsets in the - response. A name server SHOULD make every attempt to keep the RRset - and its associated RRSIG(s) together in a response. Inclusion of - RRSIG RRs in a response is subject to the following rules: - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may need to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may need to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If - this happens, the name server MUST NOT set the TC bit solely - because these RRSIG RRs didn't fit. - -3.1.2 Including DNSKEY RRs In a Response - - When responding to a query that has the DO bit set and that requests - the SOA or NS RRs at the apex of a signed zone, a security-aware - authoritative name server for that zone MAY return the zone apex - DNSKEY RRset in the Additional section. In this situation, the - DNSKEY RRset and associated RRSIG RRs have lower priority than any - other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - -3.1.3 Including NSEC RRs In a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server for a signed zone MUST include NSEC RRs in - each of the following cases: - - No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>, - but does not contain any RRsets that exactly match <SNAME, SCLASS, - STYPE>. - - Name Error: The zone does not contain any RRsets that match <SNAME, - SCLASS> either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS> but does contain an RRset that matches - <SNAME, SCLASS, STYPE> via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS>, does contain one or more RRsets that match - <SNAME, SCLASS> via wildcard name expansion, but does not contain - any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name - expansion. - - In each of these cases, the name server includes NSEC RRs in the - response to prove that an exact match for <SNAME, SCLASS, STYPE> was - not present in the zone and that the response that the name server is - returning is correct given the data that are in the zone. - - - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -3.1.3.1 Including NSEC RRs: No Data Response - - If the zone contains RRsets matching <SNAME, SCLASS> but contains no - RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST - include the NSEC RR for <SNAME, SCLASS> along with its associated - RRSIG RR(s) in the Authority section of the response (see Section - 3.1.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RR(s), the name server MUST set the TC bit (see - Section 3.1.1). - - Since the search name exists, wildcard name expansion does not apply - to this query, and a single signed NSEC RR suffices to prove the - requested RR type does not exist. - -3.1.3.2 Including NSEC RRs: Name Error Response - - If the zone does not contain any RRsets matching <SNAME, SCLASS> - either exactly or via wildcard name expansion, then the name server - MUST include the following NSEC RRs in the Authority section, along - with their associated RRSIG RRs: - o An NSEC RR proving that there is no exact match for <SNAME, - SCLASS>; and - o An NSEC RR proving that the zone contains no RRsets that would - match <SNAME, SCLASS> via wildcard name expansion. - - In some cases a single NSEC RR may prove both of these points, in - that case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - Note that this form of response includes cases in which SNAME - corresponds to an empty non-terminal name within the zone (a name - which is not the owner name for any RRset but which is the parent - name of one or more RRsets). - -3.1.3.3 Including NSEC RRs: Wildcard Answer Response - - If the zone does not contain any RRsets which exactly match <SNAME, - SCLASS> but does contain an RRset which matches <SNAME, SCLASS, - STYPE> via wildcard name expansion, the name server MUST include the - wildcard-expanded answer and the corresponding wildcard-expanded - RRSIG RRs in the Answer section, and MUST include in the Authority - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - section an NSEC RR and associated RRSIG RR(s) proving that the zone - does not contain a closer match for <SNAME, SCLASS>. If space does - not permit inclusion of the answer, NSEC and RRSIG RRs, the name - server MUST set the TC bit (see Section 3.1.1). - -3.1.3.4 Including NSEC RRs: Wildcard No Data Response - - This case is a combination of the previous cases. The zone does not - contain an exact match for <SNAME, SCLASS>, and while the zone does - contain RRsets which match <SNAME, SCLASS> via wildcard expansion, - none of those RRsets match STYPE. The name server MUST include the - following NSEC RRs in the Authority section, along with their - associated RRSIG RRs: - o An NSEC RR proving that there are no RRsets matching STYPE at the - wildcard owner name which matched <SNAME, SCLASS> via wildcard - expansion; and - o An NSEC RR proving that there are no RRsets in the zone which - would have been a closer match for <SNAME, SCLASS>. - - In some cases a single NSEC RR may prove both of these points, in - which case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - -3.1.3.5 Finding The Right NSEC RRs - - As explained above, there are several situations in which a - security-aware authoritative name server needs to locate an NSEC RR - which proves that no RRsets matching a particular SNAME exist. - Locating such an NSEC RR within an authoritative zone is relatively - simple, at least in concept. The following discussion assumes that - the name server is authoritative for the zone which would have held - the nonexistent RRsets matching SNAME. The algorithm below is - written for clarity, not efficiency. - - To find the NSEC which proves that no RRsets matching name N exist in - the zone Z which would have held them, construct sequence S - consisting of the owner names of every RRset in Z, sorted into - canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate - names. Find the name M which would have immediately preceded N in S - if any RRsets with owner name N had existed. M is the owner name of - the NSEC RR which proves that no RRsets exist with owner name N. - - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - The algorithm for finding the NSEC RR which proves that a given name - is not covered by any applicable wildcard is similar, but requires an - extra step. More precisely, the algorithm for finding the NSEC - proving that no RRsets exist with the applicable wildcard name is - precisely the same as the algorithm for finding the NSEC RR which - proves that RRsets with any other owner name do not exist: the part - that's missing is how to determine the name of the nonexistent - applicable wildcard. In practice, this is easy, because the - authoritative name server has already checked for the presence of - precisely this wildcard name as part of step (1)(c) of the normal - lookup algorithm described in Section 4.3.2 of [RFC1034]. - -3.1.4 Including DS RRs In a Response - - When responding to a query which has the DO bit set, a security-aware - authoritative name server returning a referral includes DNSSEC data - along with the NS RRset. - - If a DS RRset is present at the delegation point, the name server - MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG - RR(s). - - If no DS RRset is present at the delegation point, the name server - MUST return both the NSEC RR which proves that the DS RRset is not - present and the NSEC RR's associated RRSIG RR(s) along with the NS - RRset. The name server MUST place the NS RRset before the NSEC RRset - and its associated RRSIG RR(s). - - Including these DS, NSEC, and RRSIG RRs increases the size of - referral messages, and may cause some or all glue RRs to be omitted. - If space does not permit inclusion of the DS or NSEC RRset and - associated RRSIG RRs, the name server MUST set the TC bit (see - Section 3.1.1). - -3.1.4.1 Responding to Queries for DS RRs - - The DS resource record type is unusual in that it appears only on the - parent zone's side of a zone cut. For example, the DS RRset for the - delegation of "foo.example" is stored in the "example" zone rather - than in the "foo.example" zone. This requires special processing - rules for both name servers and resolvers, since the name server for - the child zone is authoritative for the name at the zone cut by the - normal DNS rules but the child zone does not contain the DS RRset. - - A security-aware resolver sends queries to the parent zone when - looking for a needed DS RR at a delegation point (see Section 4.2). - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - However, special rules are necessary to avoid confusing - security-oblivious resolvers which might become involved in - processing such a query (for example, in a network configuration that - forces a security-aware resolver to channel its queries through a - security-oblivious recursive name server). The rest of this section - describes how a security-aware name server processes DS queries in - order to avoid this problem. - - The need for special processing by a security-aware name server only - arises when all the following conditions are met: - o the name server has received a query for the DS RRset at a zone - cut; and - o the name server is authoritative for the child zone; and - o the name server is not authoritative for the parent zone; and - o the name server does not offer recursion. - - In all other cases, the name server either has some way of obtaining - the DS RRset or could not have been expected to have the DS RRset - even by the pre-DNSSEC processing rules, so the name server can - return either the DS RRset or an error response according to the - normal processing rules. - - If all of the above conditions are met, however, the name server is - authoritative for SNAME but cannot supply the requested RRset. In - this case, the name server MUST return an authoritative "no data" - response showing that the DS RRset does not exist in the child zone's - apex. See Appendix B.8 for an example of such a response. - -3.1.5 Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation. - - An authoritative name server is not required to verify that a zone is - properly signed before sending or accepting a zone transfer. - However, an authoritative name server MAY choose to reject the entire - zone transfer if the zone fails meets any of the signing requirements - described in Section 2. The primary objective of a zone transfer is - to ensure that all authoritative name servers have identical copies - of the zone. An authoritative name server that chooses to perform - its own zone validation MUST NOT selectively reject some RRs and - accept others. - - DS RRsets appear only on the parental side of a zone cut and are - authoritative data in the parent zone. As with any other - authoritative RRset, the DS RRset MUST be included in zone transfers - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - of the zone in which the RRset is authoritative data: in the case of - the DS RRset, this is the parent zone. - - NSEC RRs appear in both the parent and child zones at a zone cut, and - are authoritative data in both the parent and child zones. The - parental and child NSEC RRs at a zone cut are never identical to each - other, since the NSEC RR in the child zone's apex will always - indicate the presence of the child zone's SOA RR while the parental - NSEC RR at the zone cut will never indicate the presence of an SOA - RR. As with any other authoritative RRs, NSEC RRs MUST be included - in zone transfers of the zone in which they are authoritative data: - the parental NSEC RR at a zone cut MUST be included zone transfers of - the parent zone, while the NSEC at the zone apex of the child zone - MUST be included in zone transfers of the child zone. - - RRSIG RRs appear in both the parent and child zones at a zone cut, - and are authoritative in whichever zone contains the authoritative - RRset for which the RRSIG RR provides the signature. That is, the - RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be - authoritative in the parent zone, while the RRSIG for any RRset in - the child zone's apex will be authoritative in the child zone. - Parental and child RRSIG RRs at a zone cut will never be identical to - each other, since the Signer's Name field of an RRSIG RR in the child - zone's apex will indicate a DNSKEY RR in the child zone's apex while - the same field of a parental RRSIG RR at the zone cut will indicate a - DNSKEY RR in the parent zone's apex. As with any other authoritative - RRs, RRSIG RRs MUST be included in zone transfers of the zone in - which they are authoritative data. - -3.1.6 The AD and CD Bits in an Authoritative Response - - The CD and AD bits are designed for use in communication between - security-aware resolvers and security-aware recursive name servers. - These bits are for the most part not relevant to query processing by - security-aware authoritative name servers. - - A security-aware name server does not perform signature validation - for authoritative data during query processing even when the CD bit - is clear. A security-aware name server SHOULD clear the CD bit when - composing an authoritative response. - - A security-aware name server MUST NOT set the AD bit in a response - unless the name server considers all RRsets in the Answer and - Authority sections of the response to be authentic. A security-aware - name server's local policy MAY consider data from an authoritative - zone to be authentic without further validation, but the name server - MUST NOT do so unless the name server obtained the authoritative zone - via secure means (such as a secure zone transfer mechanism), and MUST - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - NOT do so unless this behavior has been configured explicitly. - - A security-aware name server which supports recursion MUST follow the - rules for the CD and AD bits given in Section 3.2 when generating a - response that involves data obtained via recursion. - -3.2 Recursive Name Servers - - As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware - recursive name server is an entity which acts in both the - security-aware name server and security-aware resolver roles. This - section uses the terms "name server side" and "resolver side" to - refer to the code within a security-aware recursive name server which - implements the security-aware name server role and the code which - implements the security-aware resolver role, respectively. - - The resolver side follows the usual rules for caching and negative - caching which would apply to any security-aware resolver. - -3.2.1 The DO bit - - The resolver side of a security-aware recursive name server MUST set - the DO bit when sending requests, regardless of the state of the DO - bit in the initiating request received by the name server side. If - the DO bit in an initiating query is not set, the name server side - MUST strip any authenticating DNSSEC RRs from the response, but MUST - NOT strip any DNSSEC RR types that the initiating query explicitly - requested. - -3.2.2 The CD bit - - The CD bit exists in order to allow a security-aware resolver to - disable signature validation in a security-aware name server's - processing of a particular query. - - The name server side MUST copy the setting of the CD bit from a query - to the corresponding response. - - The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest - of an initiating query, so that the resolver side will know whether - or not it is required to verify the response data it returns to the - name server side. If the CD bit is set, it indicates that the - originating resolver is willing to perform whatever authentication - its local policy requires, thus the resolver side of the recursive - name server need not perform authentication on the RRsets in the - response. When the CD bit is set the recursive name server SHOULD, - if possible, return the requested data to the originating resolver - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - even if the recursive name server's local authentication policy would - reject the records in question. That is, by setting the CD bit, the - originating resolver has indicated that it takes responsibility for - performing its own authentication, and the recursive name server - should not interfere. - - If the resolver side implements a BAD cache (see Section 4.7) and the - name server side receives a query which matches an entry in the - resolver side's BAD cache, the name server side's response depends on - the sense of the CD bit in the original query. If the CD bit is set, - the name server side SHOULD return the data from the BAD cache; if - the CD bit is not set, the name server side MUST return RCODE 2 - (server failure). - - The intent of the above rule is to provide the raw data to clients - which are capable of performing their own signature verification - checks while protecting clients which depend on the resolver side of - a security-aware recursive name server to perform such checks. - Several of the possible reasons why signature validation might fail - involve conditions which may not apply equally to the recursive name - server and the client which invoked it: for example, the recursive - name server's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security which the recursive name - server does not share. In such cases, "protecting" a client which is - capable of performing its own signature validation from ever seeing - the "bad" data does not help the client. - -3.2.3 The AD bit - - The name server side of a security-aware recursive name server MUST - NOT set the AD bit in a response unless the name server considers all - RRsets in the Answer and Authority sections of the response to be - authentic. The name server side SHOULD set the AD bit if and only if - the resolver side considers all RRsets in the Answer section and any - relevant negative response RRs in the Authority section to be - authentic. The resolver side MUST follow the procedure described in - Section 5 to determine whether the RRs in question are authentic. - However, for backwards compatibility, a recursive name server MAY set - the AD bit when a response includes unsigned CNAME RRs if those CNAME - RRs demonstrably could have been synthesized from an authentic DNAME - RR which is also included in the response according to the synthesis - rules described in [RFC2672]. - -3.3 Example DNSSEC Responses - - See Appendix B for example response packets. - - - - - -Arends, et al. Expires January 13, 2005 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -4. Resolving - - This section describes the behavior of entities that include - security-aware resolver functions. In many cases such functions will - be part of a security-aware recursive name server, but a stand-alone - security-aware resolver has many of the same requirements. Functions - specific to security-aware recursive name servers are described in - Section 3.2. - -4.1 EDNS Support - - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set when sending queries. - - A security-aware resolver MUST support a message size of at least - 1220 octets, SHOULD support a message size of 4000 octets, and MUST - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver - MUST handle fragmented UDP packets correctly regardless of whether - any such fragmented packets were received via IPv4 or IPv6. Please - see [RFC3226] for discussion of these requirements. - -4.2 Signature Verification Support - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and SHOULD apply them to every - received response except when: - o The security-aware resolver is part of a security-aware recursive - name server, and the response is the result of recursion on behalf - of a query received with the CD bit set; - o The response is the result of a query generated directly via some - form of application interface which instructed the security-aware - resolver not to perform validation for this query; or - o Validation for this query has been disabled by local policy. - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - Security aware resolvers MAY query for missing security RRs in an - attempt to perform validation; implementations that choose to do so - must be aware that the answers received may not be sufficient to - validate the original response. - - When attempting to retrieve missing NSEC RRs which reside on the - parental side at a zone cut, a security-aware iterative-mode resolver - MUST query the name servers for the parent zone, not the child zone. - - When attempting to retrieve a missing DS, a security-aware - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - iterative-mode resolver MUST query the name servers for the parent - zone, not the child zone. As explained in Section 3.1.4.1, - security-aware name servers need to apply special processing rules to - handle the DS RR, and in some situations the resolver may also need - to apply special rules to locate the name servers for the parent zone - if the resolver does not already have the parent's NS RRset. To - locate the parent NS RRset, the resolver can start with the - delegation name, strip off the leftmost label, and query for an NS - RRset by that name; if no NS RRset is present at that name, the - resolver then strips of the leftmost remaining label and retries the - query for that name, repeating this process of walking up the tree - until it either finds the NS RRset or runs out of labels. - -4.3 Determining Security Status of Data - - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between four - cases: - - Secure: An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted security anchor to the - RRset. In this case, the RRset should be signed, and is subject - to signature validation as described above. - - Insecure: An RRset for which the resolver knows that it has no chain - of signed DNSKEY and DS RRs from any trusted starting point to the - RRset. This can occur when the target RRset lies in an unsigned - zone or in a descendent of an unsigned zone. In this case, the - RRset may or may not be signed, but the resolver will not be able - to verify the signature. - - Bogus: An RRset for which the resolver believes that it ought to be - able to establish a chain of trust but is unable to do so, either - due to signatures that for some reason fail to validate or due to - missing data which the relevant DNSSEC RRs indicate should be - present. This case may indicate an attack, but may also indicate - a configuration error or some form of data corruption. - - Indeterminate: An RRset for which the resolver is not able to - determine whether or not the RRset should be signed, because the - resolver is not able to obtain the necessary DNSSEC RRs. This can - occur when the security-aware resolver is not able to contact - security-aware name servers for the relevant zones. - -4.4 Configured Trust Anchors - - A security-aware resolver MUST be capable of being configured with at - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - least one trusted public key or DS RR, and SHOULD be capable of being - configured with multiple trusted public keys or DS RRs. Since a - security-aware resolver will not be able to validate signatures - without such a configured trust anchor, the resolver SHOULD have some - reasonably robust mechanism for obtaining such keys when it boots; - examples of such a mechanism would be some form of non-volatile - storage (such as a disk drive) or some form of trusted local network - configuration mechanism. - - Note that trust anchors also covers key material that is updated in a - secure manner. This secure manner could be through physical media, a - key exchange protocol, or some other out of band means. - -4.5 Response Caching - - A security-aware resolver SHOULD cache each response as a single - atomic entry containing the entire answer, including the named RRset - and any associated DNSSEC RRs. The resolver SHOULD discard the - entire atomic entry when any of the RRs contained in it expire. In - most cases the appropriate cache index for the atomic entry will be - the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double <QNAME,QCLASS>. - - The reason for these recommendations is that, between the initial - query and the expiration of the data from the cache, the - authoritative data might have been changed (for example, via dynamic - update). - - There are two situations for which this is relevant: - 1. By using the RRSIG record, it is possible to deduce that an - answer was synthesized from a wildcard. A security aware - recursive name server could store this wildcard data and use it - to generate positive responses to queries other than the name for - which the original answer was first received. - 2. NSEC RRs received to prove the non-existence of a name could be - reused by a security aware resolver to prove the non-existence of - any name in the name range it spans. - - In theory, a resolver could use wildcards or NSEC RRs to generate - positive and negative responses (respectively) until the TTL or - signatures on the records in question expire. However, it seems - prudent for resolvers to avoid blocking new authoritative data or - synthesizing new data on their own. Resolvers which follow this - recommendation will have a more consistent view of the namespace. - - - - - - -Arends, et al. Expires January 13, 2005 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -4.6 Handling of the CD and AD bits - - A security-aware resolver MAY set a query's CD bit in order to - indicate that the resolver takes responsibility for performing - whatever authentication its local policy requires on the RRsets in - the response. See Section 3.2 for the effect this bit has on the - behavior of security-aware recursive name servers. - - A security-aware resolver MUST clear the AD bit when composing query - messages to protect against buggy name servers which blindly copy - header bits which they do not understand from the query message to - the response message. - - A resolver MUST disregard the meaning of the CD and AD bits in a - response unless the response was obtained using a secure channel or - the resolver was specifically configured to regard the message header - bits without using a secure channel. - -4.7 Caching BAD Data - - While many validation errors will be transient, some are likely to be - more persistent, such as those caused by administrative error - (failure to re-sign a zone, clock skew, and so forth). Since - requerying will not help in these cases, validating resolvers might - generate a significant amount of unnecessary DNS traffic as a result - of repeated queries for RRsets with persistent validation failures. - - To prevent such unnecessary DNS traffic, security-aware resolvers MAY - cache data with invalid signatures, with some restrictions. - Conceptually, caching such data is similar to negative caching - [RFC2308], except that instead of caching a valid negative response, - the resolver is caching the fact that a particular answer failed to - validate. This document refers to a cache of data with invalid - signatures as a "BAD cache". - - Resolvers which implement a BAD cache MUST take steps to prevent the - cache from being useful as a denial-of-service attack amplifier. In - particular: - o Since RRsets which fail to validate do not have trustworthy TTLs, - the implementation MUST assign a TTL. This TTL SHOULD be small, - in order to mitigate the effect of caching the results of an - attack. - o In order to prevent caching of a transient validation failure - (which might be the result of an attack), resolvers SHOULD track - queries that result in validation failures, and SHOULD only answer - from the BAD cache after the number of times that responses to - queries for that particular <QNAME, QTYPE, QCLASS> have failed to - validate exceeds a threshold value. - - - -Arends, et al. Expires January 13, 2005 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - Resolvers MUST NOT return RRsets from the BAD cache unless the - resolver is not required to validate the signatures of the RRsets in - question under the rules given in Section 4.2 of this document. See - Section 3.2.2 for discussion of how the responses returned by a - security-aware recursive name server interact with a BAD cache. - -4.8 Synthesized CNAMEs - - A validating security-aware resolver MUST treat the signature of a - valid signed DNAME RR as also covering unsigned CNAME RRs which could - have been synthesized from the DNAME RR as described in [RFC2672], at - least to the extent of not rejecting a response message solely - because it contains such CNAME RRs. The resolver MAY retain such - CNAME RRs in its cache or in the answers it hands back, but is not - required to do so. - -4.9 Stub resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - -4.9.1 Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application which - invoked it but is not required to do so. A non-validating stub - resolver that wishes to do this will need to set the DO bit in - receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, since - otherwise it will not receive the DNSSEC RRs it needs to perform - signature validation. - -4.9.2 Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless requested by the application layer, - since by definition, a non-validating stub resolver depends on the - security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - since otherwise the security-aware recursive name server will answer - the query using the name server's local policy, which may prevent the - stub resolver from receiving data which would be acceptable to the - stub resolver's local policy. - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -4.9.3 Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - which sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server, so as a practical matter there - may be little practical value to checking the status of the AD bit - except perhaps as a debugging aid. In any case, a security-aware - stub resolver MUST NOT place any reliance on signature validation - allegedly performed on its behalf except when the security-aware stub - resolver obtained the data in question from a trusted security-aware - recursive name server via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, since, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires configured knowledge of at least one authenticated - DNSKEY or DS RR. The process for obtaining and authenticating this - initial trust anchors is achieved via some external mechanism. For - example, a resolver could use some off-line authenticated exchange to - obtain a zone's DNSKEY RR or obtain a DS RR that identifies and - authenticates a zone's DNSKEY RR. The remainder of this section - assumes that the resolver has somehow obtained an initial set of - trust anchors. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag - (DNSKEY RDATA bit 7) set. - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset using an - initial DNSKEY RR, delegations from that zone can be authenticated - using DS RRs. This allows a resolver to start from an initial key, - and use DS RRsets to proceed recursively down the DNS tree obtaining - other apex DNSKEY RRsets. If the resolver were configured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as an upstream security-oblivious recursive name server - that accidentally interferes with DNSSEC RRs or due to a deliberate - attack in which an adversary forges a response, strips DNSSEC RRs - - - -Arends, et al. Expires January 13, 2005 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - from a response, or modifies a query so that DNSSEC RRs appear not to - be requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1 Special Considerations for Islands of Security - - Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed - zones for which it is not possible to construct an authentication - chain to the zone from its parent. Validating signatures within an - island of security requires the validator to have some other means of - obtaining an initial authenticated zone key for the island. If a - validator cannot obtain such a key, it SHOULD switch to operating as - if the zones in the island of security are unsigned. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a trust anchor for the authentication chain. - -5.2 Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3); - o The Algorithm and Key Tag in the DS RR match the Algorithm field - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset and, when hashed using the digest algorithm specified in the - DS RR's Digest Type field, results in a digest value that matches - the Digest field of the DS RR; and - - - -Arends, et al. Expires January 13, 2005 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - o The matching DNSKEY RR in the child zone has the Zone Flag bit - set, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the validator authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the validator can not authenticate RRsets in or below the - child zone. - - If the validator does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone, and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone, and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished, since the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3 Authenticating an RRset Using an RRSIG RR - - A validator can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The validator first checks the RRSIG - - - -Arends, et al. Expires January 13, 2005 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The validator then constructs the - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, the validator uses the public key and - signature to authenticate the signed data. Section 5.3.1, Section - 5.3.2, and Section 5.3.3 describe each step in detail. - -5.3.1 Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - o The RRSIG RR and the RRset MUST have the same owner name and the - same class; - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset; - o The RRSIG RR's Type Covered field MUST equal the RRset's type; - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field; - o The validator's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; - o The validator's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset; - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the validator cannot predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until either the signature is validated or the validator - has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - validator authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - o The apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a trust anchor. - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - - - -Arends, et al. Expires January 13, 2005 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - Section 5.3.1, the validator needs to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The validator should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | type | class | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - - - -Arends, et al. Expires January 13, 2005 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - RRset. - - The canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRset are present at the parent zone. The second NSEC RRset resides - at the child zone, and identifies which RRsets are present at the - apex in the child zone. The parent NSEC RRset and child NSEC RRset - can always be distinguished since only the child NSEC RRs will - specify an SOA RRset exists at the name. When reconstructing the - original NSEC RRset for the delegation from the parent zone, the NSEC - RRs MUST NOT be combined with NSEC RRs from the child zone, and when - reconstructing the original NSEC RRset for the apex of the child - zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent - zone. - - Note also that each of the two NSEC RRsets at a delegation point has - a corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -5.3.3 Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the validator can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types - and provides pointers to the documents that define each algorithm's - use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the validator can only - determine which DNSKEY RR by trying each matching public key until - the validator either succeeds in validating the signature or runs out - of keys to try. - - - -Arends, et al. Expires January 13, 2005 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also needs to test these RRSIG - RRs, and determines how to resolve conflicts if these RRSIG RRs lead - to differing results. - - If the resolver accepts the RRset as authentic, the validator MUST - set the TTL of the RRSIG RR and each RR in the authenticated RRset to - a value no greater than the minimum of: - o The RRset's TTL as received in the response; - o The RRSIG RR's TTL as received in the response; - o The value in the RRSIG RR's Original TTL field; and - o The difference of the RRSIG RR's Signature Expiration time and the - current time. - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the validator has verified the signature as described in Section - 5.3, it must take additional steps to verify the non-existence of an - exact match or closer wildcard match for the query. Section 5.4 - discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4 Authenticated Denial of Existence - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Denial of existence is determined by the following rules: - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - - - -Arends, et al. Expires January 13, 2005 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with - the requested name exist in the zone. However, it is possible - that a wildcard could be used to match the requested RR owner name - and type, so proving that the requested RRset does not exist also - requires proving that no possible wildcard RRset exists that could - have been used to generate a positive response. - - In addition, security-aware resolvers MUST authenticate the NSEC - RRsets that comprise the non-existence proof as described in Section - 5.3. - - To prove non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a validated NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a validator MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Resolver Behavior When Signatures Do Not Validate - - If for whatever reason none of the RRSIGs can be validated, the - response SHOULD be considered BAD. If the validation was being done - to service a recursive query, the name server MUST return RCODE 2 to - the originating client. However, it MUST return the full response if - and only if the original query had the CD bit set. See also Section - 4.7 on caching responses that do not validate. - -5.6 Authentication Example - - Appendix C shows an example the authentication process. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The additional IANA - considerations discussed in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655] and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general - security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the - DNSSEC resource record types. - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection which DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Section 3.2.2 and Section 4.9 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, - since recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will need to pay close attention to the - behavior of the applications which use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidentally denying service to the clients it - is intended to support. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -9. References - -9.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-10 (work in progress), May - 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-08 (work in progress), - May 2004. - - [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. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - -9.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - - - -Arends, et al. Expires January 13, 2005 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - 2004. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - -Arends, et al. Expires January 13, 2005 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB - 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE - VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO - 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM - W6OISukd1EQt7a0kygkg+PEDxdI= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - 3600 DNSKEY 256 3 5 ( - AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV - rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e - k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo - vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI - - - -Arends, et al. Expires January 13, 2005 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== - ) - 3600 DNSKEY 257 3 5 ( - AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl - LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ - syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP - RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT - Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 9465 example. - ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ - xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ - XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 - hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY - NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z - DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri - bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp - eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk - 7z5OXogYVaFzHKillDt3HRxHIZM= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba - U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 - 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I - BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g - sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) - 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 20040509183619 ( - 20040409183619 38519 example. - - - -Arends, et al. Expires January 13, 2005 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l - e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh - ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 - AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw - FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG - CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p - P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN - 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL - AhS+JOVfDI/79QtyTI0SaDWcg8U= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - - - -Arends, et al. Expires January 13, 2005 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE - VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb - 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH - l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw - Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - - - -Arends, et al. Expires January 13, 2005 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK - vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E - mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI - NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e - IjgiM8PXkBQtxPq37wDKALkyn7Q= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia - t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj - q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq - GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb - +gLcMZBnHJ326nb/TOOmrqNmQQE= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 - t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq - BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 - 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ - RgNvuwbioFSEuv2pNlkq0goYxNY= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - - - -Arends, et al. Expires January 13, 2005 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY - 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k - mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi - asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W - GghLahumFIpg4MO3LS/prgzVVWo= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key which should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry "*.w.example". Note that the name - "*.w.example" is used in constructing NSEC chains, and that the RRSIG - covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -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. - - ;; 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 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - - - -Arends, et al. Expires January 13, 2005 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - - -B.2 Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - - - -Arends, et al. Expires January 13, 2005 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - -B.3 No Data Error - - A "no data" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - - ;; Additional - ;; (empty) - - -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. - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; 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 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - -B.5 Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; 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. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - -B.6 Wildcard Expansion - - A successful query which 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 NSEC RR proves that no - closer match exists in the zone. - - ;; 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 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - - ;; Authority - - - -Arends, et al. Expires January 13, 2005 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - - -B.7 Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC 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. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - - - -Arends, et al. Expires January 13, 2005 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - - ;; Additional - ;; (empty) - - -B.8 DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query which was mistakenly sent - to a name server for the child zone. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1 Authenticating An Answer - - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset - was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - 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 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 labels field value of 3 indicates the answer was not - the result of wildcard expansion. The "x.w.example.com" MX RRset is - placed in canonical form and, assuming the current time falls between - the signature inception and expiration dates, the signature is - authenticated. - -C.1.1 Authenticating the example DNSKEY RR - - This example shows the logical authentication process that starts - from the a configured root DNSKEY (or DS RR) and moves down the tree - to authenticate the desired "example" DNSKEY RR. Note the logical - order is presented for clarity and an implementation may choose to - construct the authentication as referrals are received or may choose - 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 an configured DNSKEY RR for the - root zone (or a configured DS RR for the root zone). The resolver - checks this configured DNSKEY RR is present in the root DNSKEY RRset - (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this - DNSKEY RR has signed the root DNSKEY RRset and 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 the resolver may need 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 - - - -Arends, et al. Expires January 13, 2005 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - matching "example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "example" DNSKEY RRset and the signature lifetime - is valid. If all 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" - DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This - DNSKEY is used to authenticated 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 validates the signature as described - above. - -C.2 Name Error - - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3 No Data Error - - The query in section Appendix B.3 returned an NSEC RR that proves the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4 Referral to Signed Zone - - The query in section Appendix B.4 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 this DNSKEY - RR has signed the "a.example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the - "a.example" DNSKEY RRset are considered authenticated. - -C.5 Referral to Unsigned Zone - - The query in section Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - - - -Arends, et al. Expires January 13, 2005 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - "example" to "b.example" and the NSEC RR is authenticated in a manner - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion - - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as - the similar to The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The RRSIG 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 labels field value of 2 indicates the answer the - result of wildcard expansion since the "a.z.w.example" name contains - 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", - the MX RRset is placed in canonical form and, assuming the current - time falls between the signature inception and expiration dates, the - signature is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7 Wildcard No Data Error - - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8 DS Child Zone No Data Error - - The query in section Appendix B.8 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 the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 13, 2005 [Page 57] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt deleted file mode 100644 index 79a1728..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt +++ /dev/null @@ -1,1849 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: January 13, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - July 15, 2004 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-09 - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I 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 January 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describes the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Resource Records July 2004 - - - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10 - 3.1.5 Signature Expiration and Inception Fields . . . . . . 10 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19 - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19 - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19 - 5.2 Processing of DS RRs When Validating Responses . . . . . . 19 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20 - 6. Canonical Form and Order of Resource Records . . . . . . . . . 21 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 - 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32 - Intellectual Property and Copyright Statements . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 3] - -Internet-Draft DNSSEC Resource Records July 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034], [RFC1035] and subsequent RFCs that update - them: [RFC2136], [RFC2181] and [RFC2308]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is - assumed to be familiar with this document. A description of DNS - protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. - - This document defines the DNSSEC resource records. - -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]. - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Resource Records July 2004 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys and MUST NOT be used to store certificates or public keys - that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1 DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner - name MUST be the name of a zone. If bit 7 has value 0, then the - DNSKEY record holds some other type of DNS public key and MUST NOT be - used to verify RRSIGs that cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a - key intended for use as a secure entry point. This flag is only - - - -Arends, et al. Expires January 13, 2005 [Page 5] - -Internet-Draft DNSSEC Resource Records July 2004 - - - intended to be to a hint to zone signing or debugging software as to - the intended use of this DNSKEY record; validators MUST NOT alter - their behavior during the signature validation process in any way - based on the setting of this bit. This also means a DNSKEY RR with - the SEP bit set would also need the Zone Key flag set in order to - legally be able to generate signatures. A DNSKEY RR with the SEP set - and the Zone Key flag not set MUST NOT be used to verify RRSIGs that - cover RRsets. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR, and MUST be ignored upon reception. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 3 and the DNSKEY RR MUST be - treated as invalid during signature verification if found to be some - value other than 3. - -2.1.3 The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and are described in - separate documents. - -2.1.5 Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2 The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer. - Given the currently defined flags, the possible values are: 0, 256, - or 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic as specified in Appendix A.1. - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Resource Records July 2004 - - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see [RFC3548]. - -2.3 DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Resource Records July 2004 - - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator - can use these RRSIG RRs to authenticate RRsets from the zone. The - RRSIG RR MUST only be used to carry verification material (digital - signatures) used to secure DNS operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - validator can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034] that stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a signed - zone. - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR MUST match the TTL value of the RRset it - covers. This is an exception to the [RFC2181] rules for TTL values - of individual RRs within a RRset: individual RRSIG with the same - owner name will have different TTL values if the RRsets they cover - have different TTL values. - -3.1 RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset that is - covered by this RRSIG record. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that a validator - uses it to determine if the answer was synthesized from a wildcard. - If so, it can be used to determine what owner name was used in - generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will need to reconstruct the original owner name in order - to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] - describes how to use the Labels field to reconstruct the original - owner name. - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Resource Records July 2004 - - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when generating or verifying the signature. - -3.1.4 Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a validator requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic" as defined in [RFC1982]. As a direct consequence, - the values contained in these fields cannot refer to dates more than - 68 years in either the past or the future. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature, in network byte order. Appendix B explains - how to calculate Key Tag values. - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Resource Records July 2004 - - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR which a validator is supposed to use to validate this signature. - The Signer's Name field MUST contain the name of the zone of the - covered RRset. A sender MUST NOT use DNS name compression on the - Signer's Name field when transmitting a RRSIG RR. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature that covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use and these formats are described in separate companion documents. - -3.1.8.1 Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | type | class | TTL | RDATA length | RDATA - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - Any DNS names in the RDATA field of each RR MUST be in - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Resource Records July 2004 - - - canonical form; and - - The RRset MUST be sorted in canonical order. - - See Section 6.2 and Section 6.3 for details on canonical form and - ordering of RRsets. - -3.2 The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field is represented as a RR type mnemonic. When - the mnemonic is not known, the TYPE representation as described in - [RFC3597] (section 5) MUST be used. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented either as seconds since 1 January 1970 00:00:00 UTC or in - the form YYYYMMDDHHmmSS in UTC, where: - YYYY is the year (0001-9999, but see Section 3.1.5); - MM is the month number (01-12); - DD is the day of the month (01-31); - HH is the hour in 24 hours notation (00-23); - mm is the minute (00-59); and - SS is the second (00-59). - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. See - Section 2.2. - -3.3 RRSIG RR Example - - The following RRSIG RR stores the signature for the A RRset of - host.example.com: - - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Resource Records July 2004 - - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicate that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone DNSKEY RR whose algorithm is - 5 and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Resource Records July 2004 - - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the next owner - name (in the canonical ordering of the zone) which contains - authoritative data or a delegation point NS RRset, and the set of RR - types present at the NSEC RR's owner name. The complete set of NSEC - RRs in a zone both indicate which authoritative RRsets exist in a - zone and also form a chain of authoritative owner names in the zone. - This information is used to provide authenticated denial of existence - for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034] that - stated that if a CNAME is present for a name, it is the only type - allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist - for the same name as a CNAME resource record in a signed zone. - - See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone - signer determines precisely which NSEC RRs it needs to include in a - zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -4.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain field contains the next owner name (in the canonical - ordering of the zone) which has authoritative data or contains a - delegation point NS RRset; see Section 6.1 for an explanation of - canonical ordering. The value of the Next Domain Name field in the - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Resource Records July 2004 - - - last NSEC record in the zone is the name of the zone apex (the owner - name of the zone's SOA RR). This indicates that the owner name of - the NSEC RR is the last name in the canonical ordering of the zone. - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -4.1.2 The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC RR's owner name. - - 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 NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - 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, - it indicates that an RRset of that type is present for the NSEC RR's - owner name. If a bit is clear, it indicates that no RRset of that - type is present for the NSEC RR's owner name. - - Bits representing pseudo-types MUST be clear, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Resource Records July 2004 - - - interpreted as zero octets. - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and the RR - types 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. - - A zone MUST NOT include an NSEC RR for any domain name that only - holds glue records. - -4.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards - on authenticated denial of existence. - -4.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - as described in [RFC3597] (section 5) MUST be used. - -4.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the validator can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [I-D.ietf-dnsext-dnssec-protocol]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Resource Records July 2004 - - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing, but introduces special response - processing requirements for the DS RR; these are described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a one - octet Algorithm field, a one octet Digest Type field, and a Digest - field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 18] - -Internet-Draft DNSSEC Resource Records July 2004 - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record, in network byte order. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the - algorithm number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of writing, the only defined digest - algorithm is SHA-1, which produces a 20 octet digest. - -5.2 Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Resource Records July 2004 - - - have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC - zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in - the validation process. - -5.3 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4 DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Resource Records July 2004 - - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required to construct and verify RRSIG RRs. - -6.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - names ending "z.example". The names within each level are sorted in - the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - - -6.2 Canonical RR Form - - For purposes of DNS security, the canonical form of an RR is the wire - format of the RR where: - 1. Every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - 2. All uppercase US-ASCII letters in the owner name of the RR are - replaced by the corresponding lowercase US-ASCII letters; - - - - -Arends, et al. Expires January 13, 2005 [Page 21] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - 4. If the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - 5. The RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with the same owner name, class, - and type are sorted by treating the RDATA portion of the canonical - form of each RR as a left-justified unsigned octet sequence where the - absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs when - putting the RRset in canonical form, the implementation MUST treat - this as a protocol error. If the implementation chooses to handle - this protocol error in the spirit of the robustness principle (being - liberal in what it accepts), the implementation MUST remove all but - one of the duplicate RR(s) for purposes of calculating the canonical - form of the RRset. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 22] - -Internet-Draft DNSSEC Resource Records July 2004 - - -7. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by previous specifications. However, since the evolution of - DNSSEC has been long and somewhat convoluted, this section attempts - to describe the current state of the IANA registries and other - protocol parameters which are (or once were) related to DNSSEC. - - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, - and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted - use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction - security protocol described in [RFC2931] and the transaction KEY - Resource Record described in [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers, and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] - altered this registry to include flags for each entry regarding - its use with the DNS security extensions. Each algorithm entry - could refer to an algorithm that can be used for zone signing, - transaction security (see [RFC2931]) or both. Values 6-251 are - available for assignment by IETF standards action. See Appendix A - for a full listing of the DNS Security Algorithm Numbers entries - at the time of writing and their status of use in DNSSEC. - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] re-assigned all values other than 3 - to reserved and closed this IANA registry. The registry remains - closed, and all KEY and DNSKEY records are required to have - Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by - IETF Standards Action. - - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Resource Records July 2004 - - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions, and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] - and [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations related to the use of these records. - - The DS record points to a DNSKEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing such a matching DNSKEY depends on the - type of digest algorithm in use. The only currently defined digest - algorithm is SHA-1, and the working group believes that constructing - a public key which would match the algorithm, key tag, and SHA-1 - digest given in a DS record would be a sufficiently difficult problem - that such an attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation which uses only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. - - The table of algorithms in Appendix A and the key tag calculation - algorithms in Appendix B include the RSA/MD5 algorithm for - completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as - explained in [RFC3110]. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 24] - -Internet-Draft DNSSEC Resource Records July 2004 - - -9. Acknowledgments - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 25] - -Internet-Draft DNSSEC Resource Records July 2004 - - -10. References - -10.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-10 (work in progress), May - 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in - progress), May 2004. - - [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. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [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. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - - - -Arends, et al. Expires January 13, 2005 [Page 26] - -Internet-Draft DNSSEC Resource Records July 2004 - - - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 3548, July 2003. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. - - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. - -10.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - 2004. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 27] - -Internet-Draft DNSSEC Resource Records July 2004 - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 28] - -Internet-Draft DNSSEC Resource Records July 2004 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify - the security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs as described in [RFC2931] - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - -A.1.1 Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - - - -Arends, et al. Expires January 13, 2005 [Page 29] - -Internet-Draft DNSSEC Resource Records July 2004 - - - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use and the remainder of the public key area - is determined by that algorithm. Entities should only use domain - names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 30] - -Internet-Draft DNSSEC Resource Records July 2004 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but - it does not uniquely identify a DNSKEY record. Implementations MUST - NOT assume that the key tag uniquely identifies a DNSKEY RR. - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First the - RDATA (in wire format) is treated as a series of 2 octet groups, - these groups are then added together ignoring any carry bits. - - A reference implementation of the key tag algorithm is as an ANSI C - function is given below with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 31] - -Internet-Draft DNSSEC Resource Records July 2004 - - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 32] - -Internet-Draft DNSSEC Resource Records July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 13, 2005 [Page 33] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt deleted file mode 100644 index 4cfd417..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt +++ /dev/null @@ -1,639 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Clarifies STD0013 Motorola Laboratories -Expires December 2004 July 2004 - - - - Domain Name System (DNS) Case Insensitivity Clarification - ------ ---- ------ ----- ---- ------------- ------------- - <draft-ietf-dnsext-insensitive-04.txt> - - Donald E. Eastlake 3rd - - - -Status of This Document - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group at namedroppers@ops.ietf.org. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. 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. - - - -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 should not have any interoperability - consequences. - - - - - - - -D. Eastlake 3rd [Page 1] - - -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, and Scott Seligman are gratefully - acknowledged. - - - -Table of Contents - - Status of This Document....................................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.................................7 - - Copyright and Disclaimer...................................9 - Normative References.......................................9 - Informative References....................................10 - -02 to -03 Changes........................................10 - -03 to -04 Changes........................................11 - Author's Address..........................................11 - Expiration and File Name..................................11 - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -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. - - 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. - - One typographic convention for octets that do not correspond to an - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS Case Insensitivity - - - 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 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 - terms were "majuscule" and "minuscule".) - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS Case Insensitivity - - - 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 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].) - - 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. - - - - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS Case Insensitivity - - -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 input 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 may retain - the case first input for such a label or allow new input to override - the old case or even maintain separate copies preserving the input - case. - - For example, if data with owner name "foo.bar.example" is input 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" or the actual input case could be preserved. - Thus later retrieval of data stored under "xyz.bar.example" in this - case can easily return data with "xyz.BAR.example". The same - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS Case Insensitivity - - - considerations apply when inputting multiple data records with owner - names differing only in case. For example, if an "A" record is stored - as the first resourced record 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. - - 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. - - - -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 - 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 8 of [RFC 2535]. - 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 - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS Case Insensitivity - - - 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] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -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 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [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. - - [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] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Informative References - - [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 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>. - - - --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. - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS Case Insensitivity - - --03 to -04 Changes - - The following changes were made between draft version -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. - - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-786-7554 (w) - +1 508-634-2066 (h) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires December 2004. - - Its file name is draft-ietf-dnsext-insensitive-04.txt. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 11] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt deleted file mode 100644 index 123d3cc..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt +++ /dev/null @@ -1,335 +0,0 @@ - -DNS Extensions Working Group J. Schlyter -Internet-Draft August 24, 2004 -Expires: February 22, 2005 - - - RFC 3597 Interoperability Report - draft-ietf-dnsext-interop3597-01.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3667. - - 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 22, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 1] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 - 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 - 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 - 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Normative References . . . . . . . . . . . . . . . . . . . . . 4 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 - A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 - Intellectual Property and Copyright Statements . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 2] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -1. Introduction - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. The test was - performed during June and July 2004 by request of the IETF DNS - Extensions Working Group. - -2. Implementations - - The following is a list, in alphabetic order, of implementations for - compliance of RFC 3597: - - DNSJava 1.6.4 - ISC BIND 8.4.5rc4 - ISC BIND 9.3.0rc2 - NSD 2.1.1 - Net::DNS 0.47 patchlevel 1 - Nominum ANS 2.2.1.0.d - - These implementations covers the following functions (number of - implementations tested for each function in paranthesis): - - Authoritative Name Servers (4) - Full Recursive Resolver (2) - Stub Resolver (4) - DNSSEC Zone Signers (2) - -3. Tests - -3.1 Authoritative Primary Name Server - - The test zone data (Appendix A) was loaded into the name server - implementation and the server was queried for the loaded information. - -3.2 Authoritative Secondary Name Server - - The test zone data (Appendix A) was transferred using AXFR from - another name server implementation and the server was queried for the - transferred information. - -3.3 Full Recursive Resolver - - A recursive resolver was queried for resource records from a domain - with the test zone data (Appendix A). - -3.4 Stub Resolver - - A stub resolver was used to query resource records from a domain with - - - -Schlyter Expires February 22, 2005 [Page 3] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - - the test zone data (Appendix A). - -3.5 DNSSEC Signer - - A DNSSEC signer was used to sign a zone with test zone data (Appendix - A). - -4. Problems found - - Two implementations had problems with text presentation of zero - length RDATA. - - One implementation had problems with text presentation of RR type - code and classes >= 4096. - - Bug reports were filed for problems found. - -5. Summary - - Unknown type codes works in the tested authoritative servers, - recursive resolvers and stub clients. - - No changes are needed to advance RFC 3597 to draft standard. - -Normative References - - [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - -Author's Address - - Jakob Schlyter - - EMail: jakob@rfc.se - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 4] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Appendix A. Test zone data - - ; A-record encoded as TYPE1 - a TYPE1 \# 4 7f000001 - a TYPE1 192.0.2.1 - a A \# 4 7f000002 - - ; draft-ietf-secsh-dns-05.txt - sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e - - ; bogus test record (from RFC 3597) - type731 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - - ; zero length RDATA (from RFC 3597) - type62347 TYPE62347 \# 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 5] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Schlyter Expires February 22, 2005 [Page 6] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt deleted file mode 100644 index 8dcacc8..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt +++ /dev/null @@ -1,1559 +0,0 @@ - - - - - - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler -<draft-ietf-dnsext-mdns-33.txt> Microsoft -18 July 2004 - - - Linklocal Multicast Name Resolution (LLMNR) - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I 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 January 2, 2005. - -Copyright Notice - - Copyright (C) The Internet Society 2004. All rights reserved. - -Abstract - - Today, with the rise of home networking, there are an increasing - number of ad-hoc networks operating without a Domain Name System - (DNS) server. The goal of Link-Local Multicast Name Resolution - (LLMNR) is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. LLMNR supports all - current and future DNS formats, types and classes, while operating on - a separate port from DNS, and with a distinct resolver cache. Since - LLMNR only operates on the local link, it cannot be considered a - substitute for DNS. - - - - -Esibov, Aboba & Thaler Standards Track [Page 1] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 - 1.2 Terminology ..................................... 4 -2. Name resolution using LLMNR ........................... 4 - 2.1 LLMNR packet format ............................. 6 - 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 8 - 2.4 Unicast queries ................................. 11 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 - 2.7 Retransmission and jitter ....................... 13 - 2.8 DNS TTL ......................................... 13 - 2.9 Use of the authority and additional sections .... 14 -3. Usage model ........................................... 14 - 3.1 LLMNR configuration ............................. 15 -4. Conflict resolution ................................... 16 - 4.1 Considerations for multiple interfaces .......... 18 - 4.2 API issues ...................................... 19 -5. Security considerations ............................... 20 - 5.1 Scope restriction ............................... 20 - 5.2 Usage restriction ............................... 21 - 5.3 Cache and port separation ....................... 22 - 5.4 Authentication .................................. 22 -6. IANA considerations ................................... 22 -7. References ............................................ 22 - 7.1 Normative References ............................ 22 - 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 24 -Authors' Addresses ........................................... 25 -Intellectual Property Statement .............................. 25 -Disclaimer of Validity ....................................... 26 -Full Copyright Statement ..................................... 26 - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -1. Introduction - - This document discusses Link Local Multicast Name Resolution (LLMNR), - which utilizes the DNS packet format and supports all current and - future DNS formats, types and classes. LLMNR operates on a separate - port from the Domain Name System (DNS), with a distinct resolver - cache. - - The goal of LLMNR is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. These include - scenarios in which hosts are not configured with the address of a DNS - server, where configured DNS servers do not reply to a query, or - where they respond with errors, as described in Section 2. Since - LLMNR only operates on the local link, it cannot be considered a - substitute for DNS. - - Link-scope multicast addresses are used to prevent propagation of - LLMNR traffic across routers, potentially flooding the network. - LLMNR queries can also be sent to a unicast address, as described in - Section 2.4. - - Propagation of LLMNR packets on the local link is considered - sufficient to enable name resolution in small networks. The - assumption is that if a network has a gateway, then the network is - able to provide DNS server configuration. Configuration issues are - discussed in Section 3.1. - - In the future, it may be desirable to consider use of multicast name - resolution with multicast scopes beyond the link-scope. This could - occur if LLMNR deployment is successful, the need arises for - multicast name resolution beyond the link-scope, or multicast routing - becomes ubiquitous. For example, expanded support for multicast name - resolution might be required for mobile ad-hoc networking scenarios, - or where no DNS server is available that is authoritative for the - names of local hosts, and can support dynamic DNS, such as in - wireless hotspots. - - Once we have experience in LLMNR deployment in terms of - administrative issues, usability and impact on the network, it will - be possible to reevaluate which multicast scopes are appropriate for - use with multicast name resolution. - - Service discovery in general, as well as discovery of DNS servers - using LLMNR in particular, is outside of the scope of this document, - as is name resolution over non-multicast capable media. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - -1.2. Terminology - - This document assumes familiarity with DNS terminology defined in - [RFC1035]. Other terminology used in this document includes: - -Positively Resolved - Responses with RCODE set to zero are referred to in this document - as "positively resolved". - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An address is considered reachable over a link if either an ARP or - neighbor discovery cache entry exists for the address on the link. - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - -Sender - A host that sends an LLMNR query. - -2. Name resolution using LLMNR - - LLMNR is a peer-to-peer name resolution protocol that is not intended - as a replacement for DNS. LLMNR queries are sent to and received on - port 5355. IPv4 administratively scoped multicast usage is specified - in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- - scope multicast address a given responder listens to, and to which a - sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast - address a given responder listens to, and to which a sender sends all - queries, is FF02:0:0:0:0:0:1:3. - - Typically a host is configured as both an LLMNR sender and a - responder. A host MAY be configured as a sender, but not a - responder. However, a host configured as a responder MUST act as a - sender to verify the uniqueness of names as described in Section 4. - This document does not specify how names are chosen or configured. - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - This may occur via any mechanism, including DHCPv4 [RFC2131] or - DHCPv6 [RFC3315]. - - LLMNR usage MAY be configured manually or automatically on a per - interface basis. By default, LLMNR responders SHOULD be enabled on - all interfaces, at all times. Enabling LLMNR for use in situations - where a DNS server has been configured will result in a change in - default behavior without a simultaneous update to configuration - information. Where this is considered undesirable, LLMNR SHOULD NOT - be enabled by default, so that hosts will neither listen on the link- - scope multicast address, nor will they send queries to that address. - - An LLMNR sender may send a request for any name. However, by - default, LLMNR requests SHOULD be sent only when one of the following - conditions are met: - - [1] No manual or automatic DNS configuration has been - performed. If an interface has been configured with DNS - server address(es), then LLMNR SHOULD NOT be used as the - primary name resolution mechanism on that interface, although - it MAY be used as a name resolution mechanism of last resort. - - [2] DNS servers do not respond. - - [3] DNS servers respond to a DNS query with RCODE=3 - (Authoritative Name Error) or RCODE=0, and an empty - answer section. - - A typical sequence of events for LLMNR usage is as follows: - - [a] DNS servers are not configured or do not respond to a - DNS query, or respond with RCODE=3, or RCODE=0 and an - empty answer section. - - [b] An LLMNR sender sends an LLMNR query to the link-scope - multicast address(es) defined in Section 2, unless a - unicast query is indicated. A sender SHOULD send LLMNR - queries for PTR RRs via unicast, as specified in Section 2.4. - - [c] A responder responds to this query only if it is authoritative - for the domain name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.4. - - [d] Upon reception of the response, the sender processes it. - - Further details of sender and responder behavior are provided in the - sections that follow. - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -2.1. LLMNR packet format - - LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 - for both queries and responses. LLMNR implementations SHOULD send - UDP queries and responses only as large as are known to be - permissible without causing fragmentation. When in doubt a maximum - packet size of 512 octets SHOULD be used. LLMNR implementations MUST - accept UDP queries and responses as large as permitted by the link - MTU. - -2.1.1. LLMNR header format - - LLMNR queries and responses utilize the DNS header format defined in - [RFC1035] with exceptions noted below: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. - -QR A one bit field that specifies whether this message is an LLMNR - query (0), or an LLMNR response (1). - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set an LLMNR response, - then the sender MAY use the response if it contains all necessary - information, or the sender MAY discard the response and resend the - LLMNR query over TCP using the unicast address of the responder as - the destination address. See [RFC2181] and Section 2.4 of this - specification for further discussion of the TC bit. - -Z Reserved for future use. Implementations of this specification - MUST set these bits to zero in both queries and responses. If - these bits are set in a LLMNR query or response, implementations of - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the RCODE MUST be zero, and is - ignored by the responder. The response to a multicast LLMNR query - MUST have RCODE set to zero. A sender MUST silently discard an - LLMNR response with a non-zero RCODE sent in response to a - multicast query. - - If an LLMNR responder is authoritative for the name in a multicast - query, but an error is encountered, the responder SHOULD send an - LLMNR response with an RCODE of zero, no RRs in the answer section, - and the TC bit set. This will cause the query to be resent using - TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferrable to - not sending a response, since it enables errors to be diagnosed. - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - discard LLMNR queries with ANCOUNT not equal to zero. - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - -2.2. Sender behavior - - A sender may send an LLMNR query for any legal resource record type - (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. - - As described in Section 2.4, a sender may also send a unicast query. - Sections 2 and 3 describe the circumstances in which LLMNR queries - may be sent. - - The sender MUST anticipate receiving no replies to some LLMNR - queries, in the event that no responders are available within the - link-scope or in the event no positive non-null responses exist for - the transmitted query. If no positive response is received, a - resolver treats it as a response that no records of the specified - type and class exist for the specified name (it is treated the same - as a response with RCODE=0 and an empty answer section). - - Since the responder may order the RRs in the response so as to - indicate preference, the sender SHOULD preserve ordering in the - response to the querying application. - -2.3. Responder behavior - - An LLMNR response MUST be sent to the sender via unicast. - - Upon configuring an IP address responders typically will synthesize - corresponding A, AAAA and PTR RRs so as to be able to respond to - LLMNR queries for these RRs. An SOA RR is synthesized only when a - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - responder has another RR as well; the SOA RR MUST NOT be the only RR - that a responder has. However, in general whether RRs are manually - or automatically created is an implementation decision. - - For example, a host configured to have computer name "host1" and to - be a member of the "example.com" domain, and with IPv4 address - 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be - authoritative for the following records: - - host1. IN A 10.1.1.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - host1.example.com. IN A 10.1.1.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - 1.1.1.10.in-addr.arpa. IN PTR host1. - IN PTR host1.example.com. - - 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa - IN PTR host1. - IN PTR host1.example.com - - An LLMNR responder might be further manually configured with the name - of a local mail server with an MX RR included in the "host1." and - "host1.example.com." records. - - In responding to queries: - -[a] Responders MUST listen on UDP port 5355 on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port 5355 on - the unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses SHOULD always be sent - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups. - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[e] Responders MUST NOT respond using cached data. - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - -[g] If a responder is authoritative for a name, it MAY respond with - RCODE=0 and an empty answer section, if the type of query does not - match a RR that the responder has. - - As an example, a host configured to respond to LLMNR queries for the - name "foo.example.com." is authoritative for the name - "foo.example.com.". On receiving an LLMNR query for an A RR with the - name "foo.example.com." the host authoritatively responds with A - RR(s) that contain IP address(es) in the RDATA of the resource - record. If the responder has a AAAA RR, but no A RR, and an A RR - query is received, the responder would respond with RCODE=0 and an - empty answer section. - - In conventional DNS terminology a DNS server authoritative for a zone - is authoritative for all the domain names under the zone apex except - for the branches delegated into separate zones. Contrary to - conventional DNS terminology, an LLMNR responder is authoritative - only for the zone apex. - - For example the host "foo.example.com." is not authoritative for the - name "child.foo.example.com." unless the host is configured with - multiple names, including "foo.example.com." and - "child.foo.example.com.". As a result, "foo.example.com." cannot - reply to an LLMNR query for "child.foo.example.com." with RCODE=3 - (authoritative name error). The purpose of limiting the name - authority scope of a responder is to prevent complications that could - be caused by coexistence of two or more hosts with the names - representing child and parent (or grandparent) nodes in the DNS tree, - for example, "foo.example.com." and "child.foo.example.com.". - - In this example (unless this limitation is introduced) an LLMNR query - for an A resource record for the name "child.foo.example.com." would - result in two authoritative responses: RCODE=3 (authoritative name - error) received from "foo.example.com.", and a requested A record - - from "child.foo.example.com.". To prevent this ambiguity, LLMNR - enabled hosts could perform a dynamic update of the parent (or - grandparent) zone with a delegation to a child zone. In this example - a host "child.foo.example.com." would send a dynamic update for the - NS and glue A record to "foo.example.com.", but this approach - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - significantly complicates implementation of LLMNR and would not be - acceptable for lightweight hosts. - -2.4. Unicast queries and responses - - Unicast queries SHOULD be sent when: - - [a] A sender repeats a query after it received a response - with the TC bit set to the previous LLMNR multicast query, or - - [b] The sender queries for a PTR RR of a fully formed IP address - within the "in-addr.arpa" or "ip6.arpa" zones. - - Unicast LLMNR queries MUST be done using TCP and the responses MUST - be sent using the same TCP connection as the query. Senders MUST - support sending TCP queries, and responders MUST support listening - for TCP queries. If the sender of a TCP query receives a response to - that query not using TCP, the response MUST be silently discarded. - - Unicast UDP queries MUST be silently discarded. - - If TCP connection setup cannot be completed in order to send a - unicast TCP query, this is treated as a response that no records of - the specified type and class exist for the specified name (it is - treated the same as a response with RCODE=0 and an empty answer - section). - -2.5. "Off link" detection - - For IPv4, an "on link" address is defined as a link-local address - [IPv4Link] or an address whose prefix belongs to a subnet on the - local link. For IPv6 [RFC2460] an "on link" address is either a - link-local address, defined in [RFC2373], or an address whose prefix - belongs to a subnet on the local link. - - A sender MUST select a source address for LLMNR queries that is "on - link". The destination address of an LLMNR query MUST be a link- - scope multicast address or an "on link" unicast address. - - A responder MUST select a source address for responses that is "on - link". The destination address of an LLMNR response MUST be an "on - link" unicast address. - - On receiving an LLMNR query, the responder MUST check whether it was - sent to a LLMNR multicast addresses defined in Section 2. If it was - sent to another multicast address, then the query MUST be silently - discarded. - - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - Section 2.4 discusses use of TCP for LLMNR queries and responses. In - composing an LLMNR query using TCP, the sender MUST set the Hop Limit - field in the IPv6 header and the TTL field in the IPv4 header of the - response to one (1). The responder SHOULD set the TTL or Hop Limit - settings on the TCP listen socket to one (1) so that SYN-ACK packets - will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This - prevents an incoming connection from off-link since the sender will - not receive a SYN-ACK from the responder. - - For UDP queries and responses the Hop Limit field in the IPv6 header, - and the TTL field in the IPV4 header MAY be set to any value. - However, it is RECOMMENDED that the value 255 be used for - compatibility with Apple Rendezvous. - - Implementation note: - - In the sockets API for IPv4 [POSIX], the IP_TTL and - IP_MULTICAST_TTL socket options are used to set the TTL of - outgoing unicast and multicast packets. The IP_RECVTTL socket - option is available on some platforms to retrieve the IPv4 TTL of - received packets with recvmsg(). [RFC2292] specifies similar - options for setting and retrieving the IPv6 Hop Limit. - -2.6. Responder responsibilities - - It is the responsibility of the responder to ensure that RRs returned - in LLMNR responses MUST only include values that are valid on the - local interface, such as IPv4 or IPv6 addresses valid on the local - link or names defended using the mechanism described in Section 4. - In particular: - - [a] If a link-scope IPv6 address is returned in a AAAA RR, - that address MUST be valid on the local link over which - LLMNR is used. - - [b] If an IPv4 address is returned, it MUST be reachable - through the link over which LLMNR is used. - - [c] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be resolvable on the local - link over which LLMNR is used. - - Routable addresses MUST be included first in the response, if - available. This encourages use of routable address(es) for - establishment of new connections. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -2.7. Retransmission and jitter - - An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine - when to retransmit an LLMNR query and how long to collect responses - to an LLMNR query. - - If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, - then a sender MAY repeat the transmission of the query in order to - assure that it was received by a host capable of responding to it. - Retransmission of UDP queries SHOULD NOT be attempted more than 3 - times. Where LLMNR queries are sent using TCP, retransmission is - handled by the transport layer. - - Because an LLMNR sender cannot know in advance if a query sent using - multicast will receive no response, one response, or more than one - response, the sender SHOULD wait for LLMNR_TIMEOUT in order to - collect all possible responses, rather than considering the multicast - query answered after the first response is received. A unicast query - sender considers the query answered after the first response is - received, so that it only waits for LLMNR_TIMEOUT if no response has - been received. - - An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT - for each transmission. It is suggested that the computation of - LLMNR_TIMEOUT be based on the response times for earlier LLMNR - queries sent on the same interface. - - For example, the algorithms described in RFC 2988 [RFC2988] - (including exponential backoff) compute an RTO, which is used as the - value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial - RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum - RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the - maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). - - Recommended values are an initial RTO of 1 second, a minimum RTO of - 200ms, and a maximum RTO of 5 seconds. In order to avoid - synchronization, the transmission of each LLMNR query and response - SHOULD delayed by a time randomly selected from the interval 0 to 100 - ms. This delay MAY be avoided by responders responding with RRs - which they have previously determined to be UNIQUE (see Section 4 for - details). - -2.8. DNS TTL - - The responder should use a pre-configured TTL value in the records - returned an LLMNR response. A default value of 30 seconds is - RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc - networks), the TTL value may need to be reduced. - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - Due to the TTL minimalization necessary when caching an RRset, all - TTLs in an RRset MUST be set to the same value. - -2.9. Use of the authority and additional sections - - Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a - concept of delegation. In LLMNR, the NS resource record type may be - stored and queried for like any other type, but it has no special - delegation semantics as it does in the DNS. Responders MAY have NS - records associated with the names for which they are authoritative, - but they SHOULD NOT include these NS records in the authority - sections of responses. - - Responders SHOULD insert an SOA record into the authority section of - a negative response, to facilitate negative caching as specified in - [RFC2308]. The owner name of this SOA record MUST be equal to the - query name. - - Responders SHOULD NOT perform DNS additional section processing, - except as required for EDNS0 and DNSSEC. - - Senders MUST NOT cache RRs from the authority or additional section - of a response as answers, though they may be used for other purposes - such as negative caching. - -3. Usage model - - Since LLMNR is a secondary name resolution mechanism, its usage is in - part determined by the behavior of DNS implementations. This - document does not specify any changes to DNS resolver behavior, such - as searchlist processing or retransmission/failover policy. However, - robust DNS resolver implementations are more likely to avoid - unnecessary LLMNR queries. - - As noted in [DNSPerf], even when DNS servers are configured, a - significant fraction of DNS queries do not receive a response, or - result in negative responses due to missing inverse mappings or NS - records that point to nonexistent or inappropriate hosts. This has - the potential to result in a large number of unnecessary LLMNR - queries. - - [RFC1536] describes common DNS implementation errors and fixes. If - the proposed fixes are implemented, unnecessary LLMNR queries will be - reduced substantially, and so implementation of [RFC1536] is - recommended. - - For example, [RFC1536] Section 1 describes issues with retransmission - and recommends implementation of a retransmission policy based on - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - round trip estimates, with exponential backoff. [RFC1536] Section 4 - describes issues with failover, and recommends that resolvers try - another server when they don't receive a response to a query. These - policies are likely to avoid unnecessary LLMNR queries. - - [RFC1536] Section 3 describes zero answer bugs, which if addressed - will also reduce unnecessary LLMNR queries. - - [RFC1536] Section 6 describes name error bugs and recommended - searchlist processing that will reduce unnecessary RCODE=3 - (authoritative name) errors, thereby also reducing unnecessary LLMNR - queries. - -3.1. LLMNR configuration - - Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is - possible for a dual stack host to be configured with the address of a - DNS server over IPv4, while remaining unconfigured with a DNS server - suitable for use over IPv6. - - In these situations, a dual stack host will send AAAA queries to the - configured DNS server over IPv4. However, an IPv6-only host - unconfigured with a DNS server suitable for use over IPv6 will be - unable to resolve names using DNS. Automatic IPv6 DNS configuration - mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely - deployed, and not all DNS servers support IPv6. Therefore lack of - IPv6 DNS configuration may be a common problem in the short term, and - LLMNR may prove useful in enabling linklocal name resolution over - IPv6. - - Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - IPv6-only hosts may not be configured with a DNS server. Where there - is no DNS server authoritative for the name of a host or the - authoritative DNS server does not support dynamic client update over - IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not - be able to do DNS dynamic update, and other hosts will not be able to - resolve its name. - - For example, if the configured DNS server responds to AAAA RR queries - sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), - then it will not be possible to resolve the names of IPv6-only hosts. - In this situation, LLMNR over IPv6 can be used for local name - resolution. - - Similarly, if a DHCPv4 server is available providing DNS server - configuration, and DNS server(s) exist which are authoritative for - the A RRs of local hosts and support either dynamic client update - over IPv4 or DHCPv4-based dynamic update, then the names of local - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no - DNS server is authoritative for the names of local hosts, or the - authoritative DNS server(s) do not support dynamic update, then LLMNR - enables linklocal name resolution over IPv4. - - Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to - configure LLMNR on an interface. The LLMNR Enable Option, described - in [LLMNREnable], can be used to explicitly enable or disable use of - LLMNR on an interface. The LLMNR Enable Option does not determine - whether or in which order DNS itself is used for name resolution. - The order in which various name resolution mechanisms should be used - can be specified using the Name Service Search Option (NSSO) for DHCP - [RFC2937], using the LLMNR Enable Option code carried in the NSSO - data. - - It is possible that DNS configuration mechanisms will go in and out - of service. In these circumstances, it is possible for hosts within - an administrative domain to be inconsistent in their DNS - configuration. - - For example, where DHCP is used for configuring DNS servers, one or - more DHCP servers can fail. As a result, hosts configured prior to - the outage will be configured with a DNS server, while hosts - configured after the outage will not. Alternatively, it is possible - for the DNS configuration mechanism to continue functioning while - configured DNS servers fail. - - Unless unconfigured hosts periodically retry configuration, an outage - in the DNS configuration mechanism will result in hosts continuing to - use LLMNR even once the outage is repaired. Since LLMNR only enables - linklocal name resolution, this represents an unnecessary degradation - in capabilities. As a result, it is recommended that hosts without a - configured DNS server periodically attempt to obtain DNS - configuration. For example, where DHCP is used for DNS - configuration, [RFC2131] recommends a maximum retry interval of 64 - seconds. In the absence of other guidance, a default retry interval - of one (1) minute is RECOMMENDED. - -4. Conflict resolution - - The sender MUST anticipate receiving multiple replies to the same - LLMNR query, in the event that several LLMNR enabled computers - receive the query and respond with valid answers. When this occurs, - the responses may first be concatenated, and then treated in the same - manner that multiple RRs received from the same DNS server would; the - sender perceives no inherent conflict in the receipt of multiple - responses. - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - There are some scenarios when multiple responders MAY respond to the - same query. There are other scenarios when only one responder MAY - respond to a query. Resource records for which the latter queries - are submitted are referred as UNIQUE throughout this document. The - uniqueness of a resource record depends on a nature of the name in - the query and type of the query. For example it is expected that: - - - multiple hosts may respond to a query for an SRV type record - - multiple hosts may respond to a query for an A or AAAA type - record for a cluster name (assigned to multiple hosts in - the cluster) - - only a single host may respond to a query for an A or AAAA - type record for a name. - - Every responder that responds to an LLMNR query AND includes a UNIQUE - record in the response: - - [1] MUST verify that there is no other host within the - scope of the LLMNR query propagation that can return - a resource record for the same name, type and class. - - [2] MUST NOT include a UNIQUE resource record in the - response without having verified its uniqueness. - - Where a host is configured to issue LLMNR queries on more than one - interface, each interface should have its own independent LLMNR - cache. For each UNIQUE resource record in a given interface's - configuration, the host MUST verify resource record uniqueness on - that interface. To accomplish this, the host MUST send an LLMNR - query for each UNIQUE resource record. - - By default, a host SHOULD be configured to behave as though all RRs - are UNIQUE. Uniqueness verification is carried out when the host: - - - starts up or is rebooted - - wakes from sleep (if the network interface was inactive during sleep) - - is configured to respond to the LLMNR queries on an interface - enabled for transmission and reception of IP traffic - - is configured to respond to the LLMNR queries using additional - UNIQUE resource records - - detects that an interface is connected and is usable - (e.g. an IEEE 802 hardware link-state change indicating - that a cable was attached or completion of authentication - (and if needed, association) with a wireless base station - or adhoc network - - When a host that has a UNIQUE record receives an LLMNR query for that - record, the host MUST respond. After the client receives a response, - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - it MUST check whether the response arrived on an interface different - from the one on which the query was sent. If the response arrives on - a different interface, the client can use the UNIQUE resource record - in response to LLMNR queries. If not, then it MUST NOT use the - UNIQUE resource record in response to LLMNR queries. - - The name conflict detection mechanism doesn't prevent name conflicts - when previously partitioned segments are connected by a bridge. In - order to minimize the chance of conflicts in such a situation, it is - recommended that steps be taken to ensure name uniqueness. For - example, the name could be chosen randomly from a large pool of - potential names, or the name could be assigned via a process designed - to guarantee uniqueness. - - When name conflicts are detected, they SHOULD be logged. To detect - duplicate use of a name, an administrator can use a name resolution - utility which employs LLMNR and lists both responses and responders. - This would allow an administrator to diagnose behavior and - potentially to intervene and reconfigure LLMNR responders who should - not be configured to respond to the same name. - -4.1. Considerations for Multiple Interfaces - - A multi-homed host may elect to configure LLMNR on only one of its - active interfaces. In many situations this will be adequate. - However, should a host need to configure LLMNR on more than one of - its active interfaces, there are some additional precautions it MUST - take. Implementers who are not planning to support LLMNR on multiple - interfaces simultaneously may skip this section. - - A multi-homed host checks the uniqueness of UNIQUE records as - described in Section 4. The situation is illustrated in figure 1. - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. Link-scope name conflict - - In this situation, the multi-homed myhost will probe for, and defend, - its host name on both interfaces. A conflict will be detected on one - interface, but not the other. The multi-homed myhost will not be - able to respond with a host RR for "myhost" on the interface on the - right (see Figure 1). The multi-homed host may, however, be - configured to use the "myhost" name on the interface on the left. - - Since names are only unique per-link, hosts on different links could - be using the same name. If an LLMNR client sends requests over - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - multiple interfaces, and receives replies from more than one, the - result returned to the client is defined by the implementation. The - situation is illustrated in figure 2. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - - If host myhost is configured to use LLMNR on both interfaces, it will - send LLMNR queries on both interfaces. When host myhost sends a - query for the host RR for name "A" it will receive a response from - hosts on both interfaces. - - Host myhost cannot distinguish between the situation shown in Figure - 2, and that shown in Figure 3 where no conflict exists. - - [A] - | | - ----- ----- - | | - [myhost] - - Figure 3. Multiple paths to same host - - This illustrates that the proposed name conflict resolution mechanism - does not support detection or resolution of conflicts between hosts - on different links. This problem can also occur with unicast DNS - when a multi-homed host is connected to two different networks with - separated name spaces. It is not the intent of this document to - address the issue of uniqueness of names within DNS. - -4.2. API issues - - [RFC2553] provides an API which can partially solve the name - ambiguity problem for applications written to use this API, since the - sockaddr_in6 structure exposes the scope within which each scoped - address exists, and this structure can be used for both IPv4 (using - v4-mapped IPv6 addresses) and IPv6 addresses. - - Following the example in Figure 2, an application on 'myhost' issues - the request getaddrinfo("A", ...) with ai_family=AF_INET6 and - ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both - interfaces and the resolver library will return a list containing - multiple addrinfo structures, each with an associated sockaddr_in6 - structure. This list will thus contain the IPv4 and IPv6 addresses - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - of both hosts responding to the name 'A'. Link-local addresses will - have a sin6_scope_id value that disambiguates which interface is used - to reach the address. Of course, to the application, Figures 2 and 3 - are still indistinguishable, but this API allows the application to - communicate successfully with any address in the list. - -5. Security Considerations - - LLMNR is by nature a peer-to-peer name resolution protocol. It is - therefore inherently more vulnerable than DNS, since existing DNS - security mechanisms are difficult to apply to LLMNR. While tools - exist to alllow an attacker to spoof a response to a DNS query, - spoofing a response to an LLMNR query is easier since the query is - sent to a link-scope multicast address, where every host on the - logical link will be made aware of it. - - In order to address the security vulnerabilities, the following - mechanisms are contemplated: - - [1] Scope restrictions. - [2] Usage restrictions. - [3] Cache and port separation. - [4] Authentication. - - These techniques are described in the following sections. - -5.1. Scope restriction - - With LLMNR it is possible that hosts will allocate conflicting names - for a period of time, or that attackers will attempt to deny service - to other hosts by allocating the same name. Such attacks also allow - hosts to receive packets destined for other hosts. - - Since LLMNR is typically deployed in situations where no trust model - can be assumed, it is likely that LLMNR queries and responses will be - unauthenticated. In the absence of authentication, LLMNR reduces the - exposure to such threats by utilizing UDP queries sent to a link- - scope multicast address, as well as setting the TTL (IPv4) or Hop - Limit (IPv6) fields to one (1) on TCP queries and responses. - - Using a TTL of one (1) to set up a TCP connection in order to send a - unicast LLMNR query reduces the likelihood of both denial of service - attacks and spoofed responses. Checking that an LLMNR query is sent - to a link-scope multicast address should prevent spoofing of - multicast queries by off-link attackers. - - While this limits the ability of off-link attackers to spoof LLMNR - queries and responses, it does not eliminate it. For example, it is - - - -Esibov, Aboba & Thaler Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - possible for an attacker to spoof a response to a frequent query - (such as an A or AAAA query for a popular Internet host), and by - using a TTL or Hop Limit field larger than one (1), for the forged - response to reach the LLMNR sender. - - When LLMNR queries are sent to a link-scope multicast address, it is - possible that some routers may not properly implement link-scope - multicast, or that link-scope multicast addresses may leak into the - multicast routing system. - - Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than - one in an LLMNR UDP response may enable denial of service attacks - across the Internet. However, since LLMNR responders only respond to - queries for which they are authoritative, and LLMNR does not provide - wildcard query support, it is believed that this threat is minimal. - - There also are scenarios such as public "hotspots" where attackers - can be present on the same link. These threats are most serious in - wireless networks such as 802.11, since attackers on a wired network - will require physical access to the home network, while wireless - attackers may reside outside the home. Link-layer security can be of - assistance against these threats if it is available. - -5.2. Usage restriction - - As noted in Sections 2 and 3, LLMNR is intended for usage in a - limited set of scenarios. - - If an LLMNR query is sent whenever a DNS server does not respond in a - timely way, then an attacker can poison the LLMNR cache by responding - to the query with incorrect information. To some extent, these - vulnerabilities exist today, since DNS response spoofing tools are - available that can allow an attacker to respond to a query more - quickly than a distant DNS server. - - Since LLMNR queries are sent and responded to on the local-link, an - attacker will need to respond more quickly to provide its own - response prior to arrival of the response from a legitimate - responder. If an LLMNR query is sent for an off-link host, spoofing a - response in a timely way is not difficult, since a legitimate - response will never be received. - - The vulnerability is more serious if LLMNR is given higher priority - than DNS among the enabled name resolution mechanisms. In such a - configuration, a denial of service attack on the DNS server would not - be necessary in order to poison the LLMNR cache, since LLMNR queries - would be sent even when the DNS server is available. In addition, the - LLMNR cache, once poisoned, would take precedence over the DNS cache, - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - eliminating the benefits of cache separation. As a result, LLMNR is - only used as a name resolution mechanism of last resort. - -5.3. Cache and port separation - - In order to prevent responses to LLMNR queries from polluting the DNS - cache, LLMNR implementations MUST use a distinct, isolated cache for - LLMNR on each interface. The use of separate caches is most effective - when LLMNR is used as a name resolution mechanism of last resort, - since this minimizes the opportunities for poisoning the LLMNR cache, - and decreases reliance on it. - - LLMNR operates on a separate port from DNS, reducing the likelihood - that a DNS server will unintentionally respond to an LLMNR query. - -5.4. Authentication - - LLMNR implementations may not support DNSSEC or TSIG, and as a - result, responses to LLMNR queries may be unauthenticated. If - authentication is desired, and a pre-arranged security configuration - is possible, then IPsec ESP with a null-transform MAY be used to - authenticate LLMNR responses. In a small network without a - certificate authority, this can be most easily accomplished through - configuration of a group pre-shared key for trusted hosts. - -6. IANA Considerations - - This specification creates one new name space: the reserved bits in - the LLMNR header. These are allocated by IETF Consensus, in - accordance with BCP 26 [RFC2434]. - - LLMNR requires allocation of port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 224.0.0.252, as well as link-scope multicast IPv6 address - FF02:0:0:0:0:0:1:3. - -7. References - -7.1. Normative References - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - -[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 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. - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - -[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - -[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. - -7.2. Informative References - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - 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. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - -[IPV4Link] - Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of IPv4 Link-Local Addresses", Internet draft (work in - progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May - 2004. - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[NodeInfo] - Crawford, M., "IPv6 Node Information Queries", Internet draft - (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-09.txt, May 2002. - -Acknowledgments - - This work builds upon original work done on multicast DNS by Bill - Manning and Bill Woodcock. Bill Manning's work was funded under DARPA - grant #F30602-99-1-0523. The authors gratefully acknowledge their - contribution to the current specification. Constructive input has - also been received from Mark Andrews, Stuart Cheshire, Randy Bush, - Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik - Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik - Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill, - Keith Moore and Markku Savela. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -Authors' Addresses - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - Bernard Aboba - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 706 6605 - EMail: bernarda@microsoft.com - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 703 8835 - EMail: dthaler@microsoft.com - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - -Open Issues - - Open issues with this specification are tracked on the following web - site: - - http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 26] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt deleted file mode 100644 index c5c3b84..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -DNSEXT Working Group Yuji Kamite -INTERNET-DRAFT NTT Communications -<draft-ietf-dnsext-tkey-renewal-mode-04.txt> Masaya Nakayama -Expires: Aug. 2004 The University of Tokyo - Feb. 2004 - - - - - TKEY Secret Key Renewal Mode - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - 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 - - -Abstract - - This document defines a new mode in TKEY and proposes an atomic - method for changing secret keys used for TSIG periodically. - Originally, TKEY provides methods of setting up shared secrets other - than manual exchange, but it cannot control timing of key renewal - very well though it can add or delete shared keys separately. This - proposal is a systematical key renewal procedure intended for - preventing signing DNS messages with old and non-safe keys - permanently. - - - - - - - - -Kamite, et. al. [Page 1] - -INTERNET-DRAFT Feb. 2004 - - - Table of Contents - - -1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 - 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 -2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7 - 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7 - 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7 - 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8 - 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8 - 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10 - 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 - 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 - 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 - 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 - 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 -3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15 -4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15 - 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15 - 4.2 Authentication Methods Considerations . . . . . . . . . . . . 15 -5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 - 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 -6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 -7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 -8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20 -9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 -10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21 -11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 -Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 - - - - - - - - - - - - - - - -Kamite, et. al. [Page 2] - -INTERNET-DRAFT Feb. 2004 - - -1. Introduction - - TSIG [RFC2845] provides DNS message integrity and the - request/transaction authentication by means of message authentication - codes (MAC). TSIG is a practical solution in view of calculation - speed and availability. However, TSIG does not have exchanging - mechanism of shared secret keys between server and resolver, and - administrators might have to exchange secret keys manually. TKEY - [RFC2930] is introduced to solve such problem and it can exchange - secrets for TSIG via networks. - - In various modes of TKEY, a server and a resolver can add or delete a - secret key be means of TKEY message exchange. However, the existing - TKEY does not care fully about the management of keys which became - too old, or dangerous after long time usage. - - It is ideal that the number of secret which a pair of hosts share - should be limited only one, because having too many keys for the same - purpose might not only be a burden to resolvers for managing and - distinguishing according to servers to query, but also does not seem - to be safe in terms of storage and protection against attackers. - Moreover, perhaps holding old keys long time might give attackers - chances to compromise by scrupulous calculation. - - Therefore, when a new shared secret is established by TKEY, the - previous old secret should be revoked immediately. To accomplish - this, DNS servers must support a protocol for key renewal. This - document specifies procedure to refresh secret keys between two hosts - which is defined within the framework of TKEY, and it is called "TKEY - Secret Key Renewal Mode". - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - - -1.1. Defined Words - - * Inception Time: Beginning of the shared secret key lifetime. This - value is determined when the key is generated. - - * Expiry Limit: Time limit of the key's validity. This value is - determined when a new key is generated. After Expiry Limit, server - and client (resolver) must not authenticate TSIG signed with the key. - Therefore, Renewal to the next key should be carried out before - Expiry Limit. - - * Partial Revocation Time: Time when server judges the key is too old - - - -Kamite, et. al. [Page 3] - -INTERNET-DRAFT Feb. 2004 - - - and must be updated. It must be between Inception Time and Expiry - Limit. This value is determined by server freely following its - security policy. e.g., If the time from Inception to Partial - Revocation is short, renewal will be carried out more often, which - might be safer. - - * Revocation Time: Time when the key becomes invalid and can be - removed. This value is not determined in advance because it is the - actual time when revocation is completed. - - * Adoption Time: Time when the new key is adopted as the next key - formally. After Adoption, the key is valid and server and client can - generate or verify TSIG making use of it. Adoption Time also means - the time when it becomes possible to remove the previous key, so - Revocation and Adoption are usually done at the same time. - - - Partial - Inception Revocation Revocation Expiry Limit - | | | | - |----------------|- - - - - - >>|- (revoked) -| - | | | | - previous key | | | - |- - - -|-------------------->> time - | | new key - Inception Adoption - - -1.2. New Format and Assigned Numbers - - TSIG - ERROR = (PartialRevoke), TBD - - TKEY - Mode = (server assignment for key renewal), TBD - Mode = (Diffie-Hellman exchange for key renewal), TBD - Mode = (resolver assignment for key renewal), TBD - Mode = (key adoption), TBD - - -1.3. Overview of Secret Key Renewal Mode - - When a server receives a query from a client signed with a TSIG key, - It always checks if the present time is within the range of usage - duration it considers safe. If it is judged that the key is too old, - i.e., after Partial Revocation Time, the server comes to be in - Partial Revocation state about the key, and this key is called - partially revoked. - - - -Kamite, et. al. [Page 4] - -INTERNET-DRAFT Feb. 2004 - - - In this state, if a client sends a normal query (e.g., question about - A RR) other than TKEY Renewal request with TSIG signed with the old - key, the server returns an error message to notify that the time to - renew has come. This is called "PartialRevoke" error message. It is - server's choice whether it returns PartialRevoke or not. If and only - if the server is ready for changing its own key, it decides to return - PartialRevoke. - - The client which got this error is able to notice that it is - necessary to refresh the secret. To make a new shared secret, it - sends a TKEY Renewal request, in which several keying methods are - available. It can make use of TSIG authentication signed with the - partially revoked key mentioned above. - - After new secret establishment, the client sends a TKEY Adoption - request for renewal confirmation. This can also be authenticated with - the partially revoked key. If this is admitted by the server, the new - key is formally adopted, and at the same time the corresponding old - secret is invalidated. Then the client can send the first query again - signed with the new key. - - Key renewal procedure is executed based on two-phase commit - mechanism. The first phase is the TKEY Renewal request and its - response, which means preparatory confirmation for key update. The - second phase is Adoption request and its response. If the server gets - request and client receives the response successfully, they can - finish renewal process. If any error happens and renewal process - fails during these phases, client should roll back to the beginning - of the first phase, and send TKEY Renewal request again. This - rollback can be done until the Expiry Limit of the key. - - -2. Shared Secret Key Renewal - - Suppose a server and a client agree to change their TSIG keys - periodically. Key renewal procedure is defined between two hosts. - -2.1. Key Usage Time Check - - Whenever a server receives a query with TSIG and can find a key that - is used for signing it, the server checks its Inception Time, Partial - Revocation Time and Expiry Limit (this information is usually - memorized by the server). - - When the present time is before Inception Time, the server MUST NOT - verify TSIG with the key, and server acts the same way as when the - key used by the client is not recognized. It follows [RFC2845] 4.5.1. - - - - -Kamite, et. al. [Page 5] - -INTERNET-DRAFT Feb. 2004 - - - When the present time is equal to Inception Time, or between - Inception Time and Partial Revocation Time, the behavior of the - server is the same as when a valid key is found. It follows [RFC2845] - 4.5.2 and 4.5.3. - - When the present time is the same as the Partial Revocation Time, or - between the Partial Revocation Time and Expiry Limit, the server - comes to be in Partial Revocation state about the TSIG key and - behaves according to the next section. - - When the present time is the same as the Expiry Time or after it, the - server MUST NOT verify TSIG with the key, and returns error messages - in the same way as when the key used by the client is not recognized. - It follows [RFC2845] 4.5.1. - - -2.2. Partial Revocation - - In Partial Revocation state, we say the server has partially revoked - the key and the key has become a "partially revoked key". - - If server has received a query signed with the partially revoked key - for TKEY Renewal request (See section 2.3.) or Key Adoption request - (See section 2.4.), then server does proper process following each - specification. If it is for TKEY key deletion request ([RFC2930] - 4.2), server MAY process usual deletion operation defined therein. - - If server receives other types of query signed with the partially - revoked key, and both the corresponding MAC and signed TIME are - verified, then server begins returning answer whose TSIG error code - is "PartialRevoke" (See section 9.). Server MUST randomly but with - increasing frequency return PartialRevoke when in the Partial - Revocation state. - - Server can decide when it actually sends PartialRevoke, checking if - it is appropriate time for renewal. Server MUST NOT return - PartialRevoke if this is apart long lived TSIG transaction (such as - AXFR) that started before the Partial Revocation Time. - - If the client receives PartialRevoke and understands it, then it MUST - retry the query with the old key unless a new key has been adopted. - Client SHOULD start the process to renew the TSIG key. For key - renewal procedure, see details in Section 2.3 and 2.4. - - PartialRevoke period (i.e., time while server returns PartialRevoke - randomely) SHOULD be small, say 2-5% of key lifetime. This is - server's choice. - - - - -Kamite, et. al. [Page 6] - -INTERNET-DRAFT Feb. 2004 - - - Server MUST keep track of clients ignoring PartialRevoke, thus - indicating ignorance of this TKEY mode. - - PartialRevoke error messages have the role to inform clients of the - keys' partial revocation and urge them to send TKEY Renewal requests. - These error responses MUST be signed with those partial revoked keys - if the queries are signed with them. They are sent only when the - signing keys are found to be partially revoked. If the MAC of TSIG - cannot be verified with the partially revoked keys, servers MUST NOT - return PartialRevoke error with MAC, but MUST return another error - such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other - words, a server informs its key's partial revocation only when the - MAC in the received query is valid. - - -2.3. Key Renewal Message Exchange - -2.3.1. Query for Key Renewal - - If a client has received a PartialRevoke error and authenticated the - response based on TSIG MAC, it sends a TKEY query for Key Renewal (in - this document, we call it Renewal request, too.) to the server. The - request MUST be signed with TSIG or SIG(0) [RFC2931] for - authentication. If TSIG is selected, the client can sign it with the - partial revoked key. - - Key Renewal can use one of several keying methods which is indicated - in "Mode" field of TKEY RR, and its message structure is dependent on - that method. - - -2.3.2. Response for Key Renewal - - The server which has received Key Renewal request first tries to - verify TSIG or SIG(0) accompanying it. If the TSIG is signed and - verified with the partially revoked key, the request MUST be - authenticated. - - After authentication, server must check existing old key's validity. - If the partially revoked key indicated in the request TKEY's OldName - and OldAlgorithm field (See section 2.3.4.) does not exist at the - server, "BADKEY" [RFC2845] is given in Error field for response. If - any other error happens, server returns appropriate error messages - following the specification described in section 2.5. If there are no - errors, server returns a Key Renewal answer. This answer MUST be - signed with TSIG or SIG(0) for authentication. - - When this answer is successfully returned and no error is detected by - - - -Kamite, et. al. [Page 7] - -INTERNET-DRAFT Feb. 2004 - - - client, a new shared secret can be established. The details of - concrete keying procedure are given in the section 2.5. - - Note: - Sometimes Adoption message and new Renewal request will cross on - the wire. In this case the newly generated key Adoption message is - resent. - - -2.3.3. Attributes of Generated Key - - As a result of this message exchange, client comes to know the newly - generated key's attributes such as key's name, Inception Time and - Expiry Limit. They are decided by the server and told to the client; - in particular, however, once the server has decided Expiry Limit and - returned a response, it should obey the decision as far as it can. In - other words, they SHOULD NOT change time values for checking Expiry - Limit in the future without any special reason, such as security - issue like "Emergency Compulsory Revocation" described in section 8. - - On the other hand, Partial Revocation Time of this generated key is - not decided based on the request, and not informed to the client. The - server can determine any value as long as it is between Inception - Time and Expiry Limit. However, the period from Inception to Partial - Revocation SHOULD be fixed as the server side's configuration or be - set the same as the corresponding old key's one. - - Note: - Even if client sends Key Renewal request though the key described - in OldName has not been partially revoked yet, server does renewal - processes. At the moment when the server accepts such requests - with valid authentication, it MUST forcibly consider the key is - already partially revoked, that is, the key's Partial Revocation - Time must be changed into the present time (i.e., the time when - the server receives the request). - - -2.3.4. TKEY RR structure - - TKEY RR for Key Renewal message has the structure given below. In - principle, format and definition for each field follows [RFC2930]. - Note that each keying scheme sometimes needs different interpretation - of RDATA field; for detail, see section 2.5. - - Field Type Comment - ------- ------ ------- - NAME domain used for a new key, see below - TYPE u_int16_t (defined in [RFC2930]) - - - -Kamite, et. al. [Page 8] - -INTERNET-DRAFT Feb. 2004 - - - CLASS u_int16_t (defined in [RFC2930]) - TTL u_int32_t (defined in [RFC2930]) - RDLEN u_int16_t (defined in [RFC2930]) - RDATA: - Algorithm: domain algorithm for a new key - Inception: u_int32_t about the keying material - Expiration: u_int32_t about the keying material - Mode: u_int16_t scheme for key agreement - see section 9. - Error: u_int16_t see description below - Key Size: u_int16_t see description below - Key Data: octet-stream - Other Size: u_int16_t (defined in [RFC2930]) - size of other data - Other Data: newly defined: see description below - - - For "NAME" field, both non-root and root name are allowed. It may - be used for a new key's name in the same manner as [RFC2930] 2.1. - - "Algorithm" specifies which algorithm is used for agreed keying - material, which is used for identification of the next key. - - "Inception" and "Expiration" are used for the valid period of - keying material. The meanings differ somewhat according to whether - the message is request or answer, and its keying scheme. - - "Key Data" has different meanings according to keying schemes. - - "Mode" field stores the value in accordance with the keying method, - and see section 2.5. Servers and clients supporting TKEY Renewal - method MUST implement "Diffie-Hellman exchange for key renewal" - scheme. All other modes are OPTIONAL. - - "Error" is an extended RCODE which includes "PartialRevoke" value - too. See section 9. - - "Other Data" field has the structure given below. They describe - attributes of the key to be renewed. - - in Other Data filed: - - Field Type Comment - ------- ------ ------- - OldNAME domain name of the old key - OldAlgorithm domain algorithm of the old key - - - - - -Kamite, et. al. [Page 9] - -INTERNET-DRAFT Feb. 2004 - - - "OldName" indicates the name of the previous key (usually, - this is partially revoked key's name that client noticed by - PartialRevoke answer from server), and "OldAlogirthm" - indicates its algorithm. - - -2.4. Key Adoption - -2.4.1. Query for Key Adoption - - After receiving a TKEY Renewal answer, the client gets the same - secret as the server. Then, it sends a TKEY Adoption request. The - request's question section's QNAME field is the same as the NAME - filed of TKEY written below. In additional section, there is one TKEY - RR that has the structure and values described below. - - "NAME" field is the new key's name to be adopted which was already - generated by Renewal message exchange. "Algorithm" is its - algorithm. "Inception" means the key's Inception Time, and - "Expiration" means Expiry Limit. - - "Mode" field is the value of "key adoption". See section 9. - - "Other Data" field in Adoption has the same structure as that of - Renewal request message. "OldName" means the previous old key, and - "OldAlogirthm" means its algorithm. - - Key Adoption request MUST be signed with TSIG or SIG(0) for - authentication. The client can sign TSIG with the previous key. Note - that until Adoption is finished, the new key is treated as invalid, - thus it cannot be used for authentication immediately. - - -2.4.2. Response for Key Adoption - - The server which has received Adoption request, it verifies TSIG or - SIG(0) accompanying it. If the TSIG is signed with the partially - revoked key and can be verified, the message MUST be authenticated. - - If the next new key indicated by the request TKEY's "NAME" is not - present at the server, BADNAME [RFC2845] is given in Error field and - the error message is returned. - - If the next key exists but it has not been adopted formally yet, the - server confirms the previous key's existence indicated by the - "OldName" and "OldAlgorithm" field. If it succeeds, the server - executes Adoption of the next key and Revocation of the previous key. - Response message duplicates the request's TKEY RR with NOERROR, - - - -Kamite, et. al. [Page 10] - -INTERNET-DRAFT Feb. 2004 - - - including "OldName" and "OldAlgorithm" that indicate the revoked key. - - If the next key exists but it is already adopted, the server returns - a response message regardless of the substance of the request TKEY's - "OldName". In this response, Response TKEY RR has the same data as - the request's one except as to its "Other Data" that is changed into - null (i.e., "Other Size" is zero), which is intended for telling the - client that the previous key name was ignored, and the new key is - already available. - - Client sometimes has to retry Adoption request. Suppose the client - sent request signed with the partially revoked key, but its response - did not return successfully (e.g., due to the drop of UDP packet). - Client will probably retry Adoption request; however, the request - will be refused in the form of TSIG "BADKEY" error because the - previous key was already revoked. In this case, client will - retransmit Adoption request signed with the next key, and expect a - response which has null "Other Data" for confirming the completion of - renewal. - - -2.5. Keying Schemes - - In Renewal message exchanges, there are no limitations as to which - keying method is actually used. The specification of keying - algorithms is independent of the general procedure of Renewal that is - described in section 2.3. - - Now this document specifies three algorithms in this section, but - other future documents can make extensions defining other methods. - - -2.5.1. DH Exchange for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.1. This - specification only describes the difference from it and special - notice; assume that all other points, such as keying material - computation, are the exactly same as the specification of [RFC2930] - 4.1. - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - the client's Diffie-Hellman public key [RFC2539]. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - - - -Kamite, et. al. [Page 11] - -INTERNET-DRAFT Feb. 2004 - - - TKEY "Mode" field stores the value of "DH exchange for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is used as a random, following [RFC2930] 4.1. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. If - any incompatible DH key is found in the request, "BADKEY" - [RFC2845] is given in Error field for response. "FORMERR" is given - if the query included no DH KEY. - - If there are no errors, the server processes a response according - to Diffie-Hellman algorithm and returns the answer. In this - answer, there is one TKEY RR in answer section and KEY RR(s) in - additional section. - - As long as no error has occurred, all values of TKEY are equal to - that of the request message except TKEY NAME, TKEY RDLEN, RDATA's - Inception, Expiration, Key Size and Key Data. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is used as an additional nonce, following - [RFC2930] 4.1. - - The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in - the additional section and a server Diffie-Hellman KEY RR will - also be present in the answer section, following [RFC2930] 4.1. - - -2.5.2. Server Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.4. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.4. - - - -Kamite, et. al. [Page 12] - -INTERNET-DRAFT Feb. 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - used in encrypting the response. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "server assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is provided following the specification of - [RFC2930] 4.4. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the query specified no encryption key. - - If there are no errors, the server response contains one TKEY RR - in the answer section, and echoes the KEY RR provided in the query - in the additional information section. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is the assigned keying data encrypted under the - public key in the resolver provided KEY RR, which is the same as - [RFC2930] 4.4. - - -2.5.3. Resolver Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.5. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.5. - - - - -Kamite, et. al. [Page 13] - -INTERNET-DRAFT Feb. 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. TKEY RR - has the encrypted keying material and KEY RR is the server public - key used to encrypt the data. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "resolver assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is the encrypted keying material. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the server does not have the corresponding - private key for the KEY RR that was shown sin the request. - - If there are no errors, the server returns a response. The - response contains a TKEY RR in the answer section to tell the - shared key's name and its usage time values. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - -2.6. Considerations about Non-compliant Hosts - - Key Renewal requests and responses must be exchanged between hosts - which can understand them and do proper processes. PartialRevoke - error messages will be only ignored if they should be returned to - non-compliant hosts. - - Note that server does not inform actively the necessity of renewal to - clients, but inform it as responses invoked by client's query. - Server needs not care whether the PartialRevoke errors has reached - - - -Kamite, et. al. [Page 14] - -INTERNET-DRAFT Feb. 2004 - - - client or not. If client has not received yet because of any reasons - such as packet drops, it will resend the queries, and finally will be - able to get PartialRevoke information. - - -3. Secret Storage - - Every server keeps all secrets and attached information, e.g., - Inception Time, Expiry Limit, etc. safely to be able to recover from - unexpected stop. To accomplish this, formally adopted keys SHOULD be - memorized not only on memory, but also be stored in the form of some - files. It will become more secure if they are stored in ecrypted - form. - - -4. Compulsory Key Revocation - -4.1. Compulsory Key Revocation by Server - - There is a rare but possible case that although servers have already - partially revoked keys, clients do not try to send any Renewal - requests. If this state continues, in the future it will become the - time of Expiry Limit. After Expiry Limit, the keys will be expired - and completely removed, so this is called Compulsory Key Revocation - by server. - - If Expiry Limit is too distant from the Partial Revocation Time, then - even though very long time passes, clients will be able to refresh - secrets only if they add TSIG signed with those old partially revoked - keys into requests, which is not safe. - - On the other hand, if Expiry Limit is too close to Partial Revocation - Time, perhaps clients might not be able to notice their keys' Partial - Revocation by getting "PartialRevoke" errors. - - Therefore, servers should set proper Expiry Limit to their keys, - considering both their keys' safety, and enough time for clients to - send requests and process renewal. - - -4.2. Authentication Methods Considerations - - It might be ideal to provide both SIG(0) and TSIG as authentication - methods. For example: - - A client and a server start SIG(0) authentication at first, to - establish TSIG shared keys by means of "Query for Diffie-Hellman - Exchanged Keying" as described in [RFC2930] 4.1. Once they get - - - -Kamite, et. al. [Page 15] - -INTERNET-DRAFT Feb. 2004 - - - shared secret, they keep using TSIG for queries and responses. - After a while the server returns a "ParitalRevoke" error and they - begin a key renewal process. Both TSIG signed with partially - revoked keys and SIG(0) are okay for authentication, but TSIG would - be easier to use considering calculation efficiency. - - Suppose now client is halted for long time with some reason. - Because server does not execute any renewal process, it will - finally do Compulsory Revocation. Even if client restarts and sends - a key Renewal request, it will fail because old key is already - deleted at server. - - At this moment, however, if client also uses SIG(0) as another - authentication method, it can make a new shared key again and - recover successfully by sending "Query for Diffie-Hellman Exchanged - Keying" with SIG(0). - - -5. Special Considerations for Two servers' Case - - This section refers to the case where both hosts are DNS servers - which can act as full resolvers as well and using one shared key - only. If one server (called Server A) wants to refresh a shared key - (called "Key A-B"), it will await a TKEY Renewal request from the - other server (called Server B). However, perhaps Server A wants to - refresh the key right now. - - In this case, Server A is allowed to send a Renewal request to Server - B, if Server A knows the Key A-B is too old and wants to renew it - immediately. - - Note that the initiative in key renewal belongs to Server A because - it can notice the Partial Revocation Time and decide key renewal. If - Server B has information about Partial Revocation Time as well, it - can also decide for itself to send Renewal request to Server A. - However, it is not essential for both two servers have information - about key renewal timing. - -5.1. To Cope with Collisions of Renewal Requests - - At least one of two hosts which use Key Renewal must know their key - renewal information such as Partial Revocation Time. It is okay that - both hosts have it. - - Provided that both two servers know key renewal timing information, - there is possibility for them to begin partial revocation and sending - Renewal requests to each other at the same time. Such collisions will - not happen so often because Renewal requests are usually invoked when - - - -Kamite, et. al. [Page 16] - -INTERNET-DRAFT Feb. 2004 - - - hosts want to send queries, but it is possible. - - When one of two servers tries to send Renewal requests, it MUST - protect old secrets that it has partially revoked and prevent it from - being refreshed by any requests from the other server (i.e., it must - lock the old secret during the process of renewal). While the server - is sending Renewal requests and waiting responses, it ignores the - other server's Renewal requests. - - Therefore, servers might fail to change secrets by means of their own - requests to others. After failure they will try to resend, but they - should wait for random delays by the next retries. If they get any - Renewal requests from others while they are waiting, their shared - keys may be refreshed, then they do not need to send any Renewal - requests now for themselves. - - -6. Key Name Considerations - - Since both servers and clients have only to distinguish new secrets - and old ones, keys' names do not need to be specified strictly. - However, it is recommended that some serial number or key generation - time be added to the name and that the names of keys between the same - pair of hosts should have some common labels among their keys. For - example, suppose A.example.com. and B.example.com. share the key - "<serial number>.A.example.com.B.example.com." such as - "10010.A.example.com.B.example.com.". After key renewal, they change - their secret and name into "10011.A.example.com.B.example.com." - - Servers and clients must be able to use keys properly for each query. - Because TSIG secret keys themselves do not have any particular IDs to - be distinguished and would be identified by their names and - algorithm, it must be understood correctly what keys are refreshed. - - -7. Example Usage of Secret Key Renewal Mode - - This is an example of Renewal mode usage where a Server, - server.example.com, and a Client, client.exmple.com have an initial - shared secret key named "00.client.example.com.server.example.com". - - (1) The time values for key - "00.client.example.com.server.example.com" was set as follows: - Inception Time is at 1:00, Expiry Limit is at 21:00. - - (2) At Server, renewal time has been set: Partial Revocation Time - is at 20:00. - - - - -Kamite, et. al. [Page 17] - -INTERNET-DRAFT Feb. 2004 - - - (3) Suppose the present time is 19:55. If Client sends a query - signed with key "00.client.example.com.server.example.com" to ask - the IP address of "www.example.com", finally it will get a proper - answer from Server with valid TSIG (NOERROR). - - (4) At 20:05. Client sends a query to ask the IP address of - "www2.example.com". It is signed with key - "00.client.example.com.server.example.com". Server returns an - answer for the IP address. However, server has begun retuning - PartialRevoke Error randomely. This answer includes valid TSIG MAC - signed with "00.client.example.com.server.example.com", and its - Error Code indicates PartialRevoke. Client understands that the - current key is partially revoked. - - (5) At 20:06. Client sends a Renewal request to Server. This - request is signed with key - "00.client.example.com.server.example.com". It includes data such - as: - - Question Section: - QNAME = 01.client.example.com. (Client can set this freely) - TYPE = TKEY - - Additional Section: - 01.client.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a KEY RR for DH and a TSIG RR. - - (6) As soon as Server receives this request, it verifies TSIG. It - is signed with the partially revoked key - "00.client.example.com.server.example.com". and Server accepts the - request. It creates a new key by Diffie-Hellman calculation and - returns an answer which includes data such as: - - Answer Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - - -Kamite, et. al. [Page 18] - -INTERNET-DRAFT Feb. 2004 - - - Answer Section also contains KEY RRs for DH. - - Additional Section also contains a TSIG RR. - This response is signed with key - "00.client.example.com.server.example.com" without error. - - At the same time, Server decides to set the Partial Revocation Time - of this new key "01.client.example.com.server.example.com." as next - day's 15:00. - - (7) Client gets the response and checks TSIG MAC, and calculates - Diffie-Hellman. It will get a new key, and it has been named - "01.client.example.com.server.example.com" by Server. - - (8) At 20:07. Client sends an Adoption request to Server. This - request is signed with the previous key - "00.client.example.com.server.example.com". It includes: - - Question Section: - QNAME = 01.client.example.com.server.example.com. - TYPE = TKEY - - Additional Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (key adoption) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a TSIG RR. - - (9) Server verifies the query's TSIG. It is signed with the - previous key and authenticated. It returns a response whose TKEY RR - is the same as the request's one. The response is signed with key - "00.client.example.com.server.example.com.". As soon as the - response is sent, Server revokes and removes the previous key. At - the same time, key "01.client.example.com.server.example.com." is - validated. - - (10) Client acknowledges the success of Adoption by receiving the - response. Then, it retries to send an original question about - "www2.example.com". It is signed with the adopted key - "01.client.example.com.server.example.com", so Server authenticates - it and returns an answer. - - - - - -Kamite, et. al. [Page 19] - -INTERNET-DRAFT Feb. 2004 - - - (11) This key is used until next day's 15:00. After that, it will - be partially revoked again. - - -8. Security Considerations - - This document considers about how to refresh shared secret. Secret - changed by this method is used at servers in support of TSIG - [RFC2845]. - - [RFC2104] says that current attacks to HMAC do not indicate a - specific recommended frequency for key changes but periodic key - refreshment is a fundamental security practice that helps against - potential weaknesses of the function and keys, and limits the damage - of an exposed key. TKEY Secret Key Renewal provides the method of - periodical key refreshment. - - In TKEY Secret Key Renewal, clients need to send two requests - (Renewal and Adoption) and spend time to finish their key renewal - processes. Thus the usage period of secrets should be considered - carefully based on both TKEY processing performance and security. - - This document specifies the procedure of periodical key renewal, but - actually there is possibility for servers to have no choice other - than revoking their secret keys immediately especially when the keys - are found to be compromised by attackers. This is called "Emergency - Compulsory Revocation". For example, suppose the original Expiry - Limit was set at 21:00, Partial Revocation Time at 20:00 and - Inception Time at 1:00. if at 11:00 the key is found to be - compromised, the server sets Expiry Limit forcibly to be 11:00 or - before it. - - Consequently, once Compulsory Revocation (See section 4.) is carried - out, normal renewal process described in this document cannot be done - any more as far as the key is concerned. However, after such - accidents happened, the two hosts are able to establish secret keys - and begin renewal procedure only if they have other (non-compromised) - shared TSIG keys or safe SIG(0) keys for the authentication of - initial secret establishment such as Diffie-Hellman Exchanged Keying. - - -9. IANA Considerations - - IANA needs to allocate a value for "DH exchange for key renewal", - "server assignment for key renewal", "resolver assignment for key - renewal" and "key adoption" in the mode filed of TKEY. It also needs - to allocate a value for "PartialRevoke" from the extended RCODE - space. - - - -Kamite, et. al. [Page 20] - -INTERNET-DRAFT Feb. 2004 - - -10. Acknowledgement - - The authors would like to thank Olafur Gudmundsson, whose helpful - input and comments contributed greatly to this document. - - -11. References - -[RFC2104] - H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message - Authentication", RFC2104, February 1997. - -[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - -[RFC2539] - D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", RFC 2539, March 1999. - -[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, - May 2000. - -[RFC2930] - D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', - RFC 2930, September 2000. - -[RFC2931] - D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s - )", RFC 2931, September 2000. - - - - - - - - - - - - - - - - - - - -Kamite, et. al. [Page 21] - -INTERNET-DRAFT Feb. 2004 - - -Authors' Addresses - - Yuji Kamite - NTT Communications Corporation - Tokyo Opera City Tower - 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo - 163-1421, Japan - EMail: y.kamite@ntt.com - - - Masaya Nakayama - Information Technology Center, The University of Tokyo - 2-11-16 Yayoi, Bunkyo-ku, Tokyo - 113-8658, Japan - EMail: nakayama@nc.u-tokyo.ac.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kamite, et. al. [Page 22] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt deleted file mode 100644 index 1133b0c..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt +++ /dev/null @@ -1,466 +0,0 @@ - - -INTERNET-DRAFT Donald E. Eastlake 3rd -UPDATES RFC 2845 Motorola Laboratories -Expires: February 2005 August 2004 - - - HMAC SHA TSIG Algorithm Identifiers - ---- --- ---- --------- ----------- - <draft-ietf-dnsext-tsig-sha-00.txt> - - -Status of This Document - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - or will be disclosed, and any of which I become aware will be - disclosed, in accordance with RFC 3668. - - 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 for additional HMAC SHA TSIG - algorithms and standardizes how to specify the truncation of HMAC - values. - - -Copyright Notice - - Copyright (C) The Internet Society 2004. All Rights Reserved. - - - - -D. Eastlake 3rd [Page 1] - - -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 - - 4. IANA Considerations.....................................6 - 5. Security Considerations.................................6 - 6. Copyright and Disclaimer................................6 - - 7. Normative References....................................7 - 8. Informative References..................................7 - - Authors Address............................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -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. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -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-1, 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 sha224] with 224, 256, 384, and 512 - bits, may be preferred in some case. Use of TSIG between a DNS - resolver and server is by mutual agreement. That agreement can - include the support of additional algorithms. - - For completeness in relation to HMAC based algorithms, the current - HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below. - Implementations which support TSIG MUST implement HMAC MD5, SHOULD - implement HMAC SHA-1, and MAY implement gss-tsig and the other - algorithms listed below. - - Mandatory HMAC-MD5.SIG-ALG.REG.INT - Recommended hmac-sha1 - Optional hmac-sha224 - Optional hmac-sha256 - Optional hamc-sha384 - Optional hmac-sha512 - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -3. Specifying Truncation - - In some cases, it is reasonable to truncate the output of HMAC and - use the truncated value for authentication. HMAC SHA-1 truncated to - 96 bits is an optional 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. - - The specification for TSIG handling is changed as follows: - - 1. If The "MAC size" field is larger than the HMAC output length or - is zero: 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 the "MAC size" field equals the HMAC output length: Operation - is as described in [RFC 2845]. - - 3. If the "MAC size" field is less than the HMAC output length but is - not zero: This is sent when the signer has truncated the HMAC - output 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. - - TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12 - octets) and MAY implement any or all other truncations valid under - case 3 above. - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -4. IANA Considerations - - This document, on approval for publication as a standards track RFC, - registers the new TSIG algorithm identifiers listed in Section 2 with - IANA. - - - -5. Security Considerations - - For all of the message authentication code algorithms listed herein, - those producing longer values are believed to be stronger; however, - while there are 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 force. See [RFC 2104] which recommends - that ah HMAC never be truncated to less than half its length nor to - less than 80 bits (10 octets). - - See also the Security Considerations section of [RFC 2845]. - - - -6. Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78 and except - as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -7. Normative References - - [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal - Information Processing Standard, Draft, 1 August 2002. - - [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 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R. - Housley, December 2003, work in progress, draft-ietf-pkix- - sha224-*.txt. - - - -8. Informative References. - - [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information - Processing Standard, 17 April 1995. - - [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. - - - - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Authors Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - +1-508-634-2066 (h) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in February 2005. - - Its file name is draft-ietf-dnsext-tsig-sha-00.txt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt deleted file mode 100644 index d65fa71..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt +++ /dev/null @@ -1,1010 +0,0 @@ - - - - - - -dnsext Working Group B. Halley -Internet Draft Nominum -Expiration Date: March 2004 - E. Lewis - ARIN - - September 2003 - - - Clarifying the Role of Wild Card Domains - in the Domain Name System - - - draft-ietf-dnsext-wcard-clarify-02.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - 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. - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - -Abstract - - The definition of wild cards is recast from the original in RFC 1034, - in words that are more specific and in line with RFC 2119. This - document is meant to supplement the definition in RFC 1034 and to - alter neither the spirit nor intent of that definition. - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 1] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Table of Contents - - Abstract ................................................ 1 - 1 Introduction ............................................ 2 - 1.1 Document Limits ......................................... 3 - 1.2 Existence ............................................... 4 - 1.3 An Example .............................................. 4 - 1.4 Empty Non-terminals ..................................... 5 - 1.5 Terminology ............................................. 6 - 2 Defining the Wild Card Domain Name ...................... 7 - 3 Defining Existence ...................................... 8 - 4 Impact of a Wild Card In a Query or in RDATA ............ 8 - 5 Impact of a Wild Card Domain On a Response .............. 9 - 6 Considerations with Special Types ....................... 12 - 6.1 SOA RR's at a Wild Card Domain Name ..................... 12 - 6.2 NS RR's at a Wild Card Domain Name ...................... 12 - 6.3 CNAME RR's at a Wild Card Domain Name ................... 13 - 6.4 DNAME RR's at a Wild Card Domain Name ................... 13 - 7 Security Considerations ................................. 14 - 8 References .............................................. 14 - 9 Others Contributing to This Document .................... 14 - 10 Editors ................................................. 15 - Appendix A: Subdomains of Wild Card Domain Names ........ 16 - Full Copyright Statement ................................ 18 - Acknowledgement ......................................... 18 - - - - -1. Introduction - - The first section of this document will give a crisp overview of what - is begin defined, as well as the motivation rewording of an original - document and making a change to bring the specification in line with - implementations. Examples are included to help orient the reader. - - Wild card domain names are defined in Section 4.3.3. of RFC 1034 as - "instructions for synthesizing RRs." [RFC1034]. The meaning of this - is that a specific, special domain name is used to construct - responses in instances in which the query name is not otherwise - represented in a zone. - - A wild card domain name has a specific range of influence on query - names (QNAMEs) within a given class, which is rooted at the domain - name containing the wild card label, and is limited by explicit - entries, zone cuts and empty non-terminal domains (see section 1.3 of - this document). - - - - -Halley & Lewis [Expires March 2004] [Page 2] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Note that a wild card domain name has no special impact on the search - for a query type (QTYPE). If a domain name is found that matches the - QNAME (exact or a wild card) but the QTYPE is not found at that - point, the proper response is that there is no data available. The - search does not continue on to seek other wild cards that might match - the QTYPE. To illustrate, a wild card owning an MX RR does not - 'cover' other names in the zone that own an A RR. There are certain - special case RR types that will be singled out for discussion, the - SOA RR, NS RR, CNAME RR, and DNAME RR. - - Why is this document needed? Empirical evidence suggests that the - words in RFC 1034 are not clear enough. There exist a number of - implementations that have strayed (each differently) from that - definition. There also exists a misconception of operators that the - wild card can be used to add a specific RR type to all names, such as - the MX RR example cited above. This document is also needed as input - to efforts to extend DNS, such as the DNS Security Extensions [RFC - 2535]. Lack of a clear base specification has proven to result in - extension documents that have unpredictable consequences. (This is - true in general, not just for DNS.) - - Another reason this clarification is needed is to answer questions - regarding authenticated denial of existence, a service introduced in - the DNS Security Extensions [RFC 2535]. Prior to the work leading up - to this document, it had been feared that a large number of proof - records (NXTs) might be needed in each reply because of the unknown - number of potential wild card domains that were thought to be - applicable. One outcome of this fear is a now discontinued document - solving a problem that is now known not to exist. I.e., this - clarification has the impact of defending against unwarranted - protocol surgery. It is not "yet another" effort to just rewrite the - early specifications for the sake of purity. - - Although the effort to define the DNS Security Extensions has - prompted this document, the clarifications herein relate to basic DNS - only. No DNS Security Extensions considerations are mentioned in the - document. - -1.1. Document Limits - - This document limits itself to reinforcing the concepts in RFC 1034. - In the effort to do this, a few issues have been discussed that - change parts of what is in RFC 1034. The discussions have been held - within the DNS Extensions Working Group. - - - - - - - -Halley & Lewis [Expires March 2004] [Page 3] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Briefly, the issues raised include: - - The lack of clarity in the definition of domain name existence - - Implications of a wild card domain name owning any of the - following resource record sets: DNAME [RFC 2672], CNAME, NS, and - SOA - - Whether RFC 1034 meant to allow special processing of CNAME RR's - owned by wild card domain names - -1.2. Existence - - The notion that a domain name 'exists' will arise numerous times in - this discussion. RFC 1034 raises the issue of existence in a number - of places, usually in reference to non-existence and often in - reference to processing involving wild card domain names. RFC 1034 - contains algorithms that describe how domain names impact the - preparation of an answer and does define wild cards as a means of - synthesizing answers. Because of this a discussion on wild card - domain names has to start with the issue of existence. - - To help clarify the topic of wild cards, a positive definition of - existence is needed. Complicating matters, though, is the - realization that existence is relative. To an authoritative server, - a domain name exists if the domain name plays a role following the - algorithms of preparing a response. To a resolver, a domain name - exists if there is any data available corresponding to the name. The - difference between the two is the synthesis of records according to a - wild card. - - For the purposes of this document, the point of view of an - authoritative server is adopted. A domain name is said to exist if - it plays a role in the execution of the algorithms in RFC 1034. - -1.3. An Example - - For example, consider this wild card domain name: *.example. Any - query name under example. is a candidate to be matched (answered) by - this wild card, i.e., to have an response returned that is - synthesized from the wild card's RR sets. Although any name is a - candidate, not all queries will match. - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 4] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - To further illustrate this, consider this zone: - - $ORIGIN example. - @ IN SOA - NS - NS - * TXT "this is a wild card" - MX 10 mailhost.example. - host1 A 10.0.0.1 - _ssh._tcp.host1 SRV - _ssh._tcp.host2 SRV - subdel NS - - - The following queries would be synthesized from the wild card: - - 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 '*' - - The following queries would not be synthesized from the wild card: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN - because host2.example. exists (without data) - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists and is a zone cut - - To the server, the following domains are considered to exist in the - zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, - _ssh._tcp.host2, and subdel. To a resolver, many more domains appear - to exist via the synthesis of the wild card. - -1.4. Empty Non-terminals - - Empty non-terminals are domain names that own no data but have - subdomains. This is defined 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. - - - - -Halley & Lewis [Expires March 2004] [Page 5] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized. According to the definition of - existence in this document, empty non-terminals do exist at the - server. - - Carefully 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 [RFC 1035]. 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, this is not the intent of the original - document. - - RFC1034's wording is to be clarified by adding the following - paragraph: - - A node is considered to have an impact on the algorithms of - 4.3.2 if it is a leaf node with any resource sets or an interior - node, with or without a resource set, that has a subdomain that - is a leaf node with a resource set. A QNAME and QCLASS matching - an existing node never results in a response return code of - authoritative name error. - - The terminology in the above paragraph is chosen to remain as close - to that in the original document. The term "with" is a alternate - form for "owning" in this case, hence "a leaf node owning resources - sets, or an interior node, owning or not owning any resource set, - that has a leaf node owning a resource set as a subdomain," is the - proper interpretation of the middle sentence. - - As an aside, an "authoritative name error" has been called NXDOMAIN - in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic - assigned to such an error by at least one implementation of DNS. As - this mnemonic is specific to implementations, it is avoided in the - remainder of this document. - -1.5. 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 the document entitled - "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] - - Requirements are denoted by paragraphs that begin with with the - following convention: 'R'<sect>.<count>. - - - -Halley & Lewis [Expires March 2004] [Page 6] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Quotations of RFC 1034 (as has already been done once above) are - denoted by a '#' in the leftmost column. - -2. Defining the Wild Card Domain Name - - A wild card domain name is defined by having the initial label be: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - This defines domain names that may play a role in being a wild card, - that is, being a source for synthesized answers. Domain names - conforming to this definition that appear in queries and RDATA - sections do not have any special role. These cases will be described - in more detail in following sections. - - R2.1 A domain name that is to be interpreted as a wild card MUST - begin with a label of '0000 0001 0010 1010' in binary. - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC 20] for - the '*' character. In RFC 1034, ASCII encoding is assumed to be the - character encoding. - - In the master file formats used in RFCs, a "*" is a legal - representation for the wild card label. Even if the "*" is escaped, - it is still interpreted as the wild card when it is the only - character in the label. - - R2.2 A server MUST treat a wild card domain name as the basis of - synthesized answers regardless of any "escape" sequences in the - input format. - - RFC 1034 and RFC 1035 ignore the case in which a domain name might be - "the*.example.com." The interpretation is that this domain name in a - zone would only match queries for "the*.example.com" and not have any - other role. - - Note: By virtue of this definition, a wild card domain name may have - a subdomain. The subdomain (or sub-subdomain) itself may also be a - wild card. E.g., *.*.example. is a wild card, so is *.sub.*.example. - More discussion on this is given in Appendix A. - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 7] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -3. Defining Existence - - As described in the Introduction, a precise definition of existence - is needed. - - R3.1 An authoritative server MUST treat a domain name as existing - during the execution of the algorithms in RFC 1034 when the - domain name conforms to the following definition. A domain name - is defined to exist if the domain name owns data and/or has a - subdomain that exists. - - Note that at a zone boundary, the domain name owns data, including - the NS RR set. At the delegating server, the NS RR set is not - authoritative, but that is of no consequence here. The domain name - owns data, therefore, it exists. - - R3.2 An authoritative server MUST treat a domain name that has - neither a resource record set nor an existing subdomain as non- - existent when executing the algorithm in section 4.3.2. of RFC - 1034. - - A note on terminology. A domain transcends zones, i.e., all DNS data - is in the root domain but segmented into zones of control. In this - document, there are references to a "domain name" in the context of - existing "in a zone." In this usage, a domain name is the root of a - domain, not the entire domain. The domain's root point is said to - "exist in a zone" if the zone is authoritative for the name. RR sets - existing in a domain need not be owned by the domain's root domain - name, but are owned by other domain names in the domain. - -4. Impact of a Wild Card In a Query or in RDATA - - When a wild card domain name appears in a question, e.g., the query - name is "*.example.", the response in no way differs from any other - query. In other words, the wild card label in a QNAME has no special - meaning, and query processing will proceed using '*' as a literal - query name. - - R4.1 A wild card domain name acting as a QNAME MUST be treated as any - other QNAME, there MUST be no special processing accorded it. - - If a wild card domain name appears in the RDATA of a CNAME RR or any - other RR that has a domain name in it, the same rule applies. In the - instance of a CNAME RR, the wild card domain name is used in the same - manner of as being the original QNAME. For other RR's, rules vary - regarding what is done with the domain name(s) appearing in them, in - no case does the wild card hold special meaning. - - - - -Halley & Lewis [Expires March 2004] [Page 8] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - R4.2 A wild card domain name appearing in any RR's RDATA MUST be - treated as any other domain name in that situation, there MUST - be no special processing accorded it. - -5. Impact of a Wild Card Domain On a Response - - The description of how wild cards impact response generation is in - RFC 1034, 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 wild card. - The algorithm is directly quoted in lines that begin with a '#' sign. - Commentary is interleaved. - - There is a documentation issue deserving some explanation. The - algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo - code, i.e., it's steps are not intended to be followed in strict - order. The "algorithm" is a suggestion. As such, in step 3, parts - a, b, and c, do not have to be implemented in that order. - - Another issue needing explanation is that RFC 1034 is a full - standard. There is another RFC, RFC 2672, which makes, or proposes - an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME - RR. RFC 2672 is a proposed standard. The dilemma in writing these - clarifications is knowing which document is the one being clarified. - Fortunately, the difference between RFC 1034 and RFC 2672 is not - significant with respect to wild card synthesis, so this document - will continue to state that it is clarifying RFC 1034. If RFC 2672 - progresses along the standards track, it will need to refer to - modifying RFC 1034's algorithm as amended here. - - The context of part 'c' is that the search is progressing label by - label through the QNAME. (Note that the data being searched is the - authoritative data in the server, the cache is searched in step 4.) - Step 3's part 'a' covers the case that the QNAME has been matched in - full, regardless of the presence of a CNAME RR. Step 'b' covers - crossing a cut point, resulting in a referral. All that is left is - to look for the wild card. - - Step 3 of the algorithm also assumes that the search is looking in - the zone closest to the answer, i.e., in the same class as QCLASS and - as close to the authority as possible on this server. If the zone is - not the authority, then a referral is given, possibly one indicating - lameness. - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 9] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if a -# the "*" label exists. - - The above paragraph refers to finding the domain name that exists in - the zone and that most encloses the QNAME. Such a domain name will - mark the boundary of candidate wild card domain names that might be - used to synthesize an answer. (Remember that at this point, if the - most enclosing name is the same as the QNAME, part 'a' would have - recorded an exact match.) The existence of the enclosing name means - that no wild card name higher in the tree is a candidate to answer - the query. - - Once the closest enclosing node is identified, there's the matter of - what exists below it. It may have subdomains, but none will be - closer to the QNAME. One of the subdomains just might be a wild - card. If it exists, this is the only wild card eligible to be used - to synthesize an answer for the query. Even if the closest enclosing - node conforms to the syntax rule in section 2 for being a wild card - domain name, the closest enclosing node is not eligible to be a - source of a synthesized answer. - - The only wild card domain name that is a candidate to synthesize an - answer will be the "*" subdomain of the closest enclosing domain - name. Three possibilities can happen. The "*" subdomain does not - exist, the "*" subdomain does but does not have an RR set of the same - type as the QTYPE, or it exists and has the desired RR set. - - For the sake of brevity, the closest enclosing node can be referred - to as the "closest encloser." The closest encloser is the most - important concept in this clarification. Describing the closest - encloser is a bit tricky, but it is an easy concept. - - To find the closest encloser, you have to first locate the zone that - is the authority for the query name. This eliminates the need to be - concerned that the closest encloser is a cut point. In addition, we - can assume too that the query name does not exist, hence the closest - encloser is not equal to the query name. We can assume away these - two cases because they are handled in steps 2, 3a and 3b of section - 4.3.2.'s algorithm. - - What is left is to identify the existing domain name that would have - been up the tree (closer to the root) from the query name. Knowing - that an exact match is impossible, if there is a "*" label descending - from the unique closest encloser, this is the one and only wild card - from which an answer can be synthesized for the query. - - - - - -Halley & Lewis [Expires March 2004] [Page 10] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - To illustrate, using the example in section 1.2 of this document, the - following chart shows QNAMEs and the closest enclosers. In - Appendix A there is another chart showing unusual cases. - - QNAME Closest Encloser Wild Card Source - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no wild card - _telnet._tcp.host2.example. host2.example. no wild card - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - - Note that host1.subdel.example. is in a subzone, so the search for it - ends in a referral in part 'b', thus does not enter into finding a - closest encloser. - - The fact that a closest encloser will be the only superdomain that - can have a candidate wild card will have an impact when it comes to - designing authenticated denial of existence proofs. - -# 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. - - The above passage says that if there is not even a wild card domain - name to match at this point (failing to find an explicit answer - elsewhere), we are to return an authoritative name error at this - point. If we were following a CNAME, the specification is unclear, - but seems to imply that a no error return code is appropriate, with - just the CNAME RR (or sequence of CNAME RRs) in the answer section. - -# 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. - - This final paragraph covers the role of the QTYPE in the process. - Note that if no resource record set matches the QTYPE the result is - that no data is copied, but the search still ceases ("Go to step - 6."). In the following section, a suggested change is made to this, - under the heading "CNAME RRs at a Wild Card Domain Name." - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 11] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -6. Considerations with Special Types - - For the purposes of this section, "special" means that a record - induces processing at the server beyond simple lookup. The special - types in this section are SOA, NS, CNAME, and DNAME. SOA is special - because it is used as a zone marker and has an impact on step 2 of - the algorithm in 4.3.2. NS denotes a cut point and has an impact on - step 3b. CNAME redirects the query and is mentioned in steps 3a and - 3b. DNAME is a "CNAME generator." - -6.1. SOA RR's at a Wild Card Domain Name - - If the owner of an SOA record conforms to the basic rules of owning - an SOA RR (meaning it is the apex of a zone) the impact on the search - algorithm is not in section 3c (where records are synthesized) as - would be expected. The impact is really in step 2 of the algorithm, - the choice of zone. - - We are no longer talking about whether or not an SOA RR can be - synthesized in a response because we are shifting attention to step - 2. We are now talking about what it means for a name server to - synthesize a zone for a response. To date, no implementation has - done this. Thinking ahead though, anyone choosing to pursue this - would have to be aware that a server would have to be able to - distinguish between queries for data it will have to synthesize and - queries that ought to be treated as if they were prompted by a lame - delegation. - - It is not a protocol error to have an SOA RR owned by a wild card - domain name, just as it is not an error to have zone name be - syntactically equivalent to a domain name. However, this situation - requires careful consideration of how a server chooses the - appropriate zone for an answer. And an SOA RR is not able to be - synthesized as in step 3c. - -6.2. NS RR's at a Wild Card Domain Name - - Complimentary to the issue of an SOA RR owned by a wild card domain - name is the issue of NS RR's owned by a wild card domain name. In - this instance, each machine being referred to in the RDATA of the NS - RR has to be able to understand the impact of this on step 2, the - choosing of the authoritative zone. - - Referring to the same machine in such a NS RR will probably not work - well. This is because the server may become confused as to whether - the query name ought to be answered by the zone owning the NS RR in - question or a synthesized zone. (It isn't known in advance that the - query name will invoke the wild card synthesis.) - - - -Halley & Lewis [Expires March 2004] [Page 12] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - The status of other RR's owned by a wild card domain name is the same - as if the owner name was not a wild card domain name. I.e., when - there is a NS RR at a wild card domain name, other records are - treated as being below the zone cut. - - Is it not a protocol error to have a NS RR owned by a wild card - domian name, complimentary to the case of a SOA RR. However, for - this to work, an implementation has to know how to synthesize a zone. - -6.3. CNAME RR's at a Wild Card Domain Name - - The issue of CNAME RR's owned by wild card domain names has prompted - a suggested change to the last paragraph of step 3c of the algorithm - in 4.3.2. The changed text is this: - - If the "*" label does exist and if the data at the node is a - CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response, set the owner of the CNAME RR to - be QNAME, and then change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - If the "*" label does exist and either QTYPE is CNAME or the - data at the node is not a CNAME, then 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. - - Apologies if the above isn't clear, but an attempt was made to stitch - together the passage using just the phrases in section 3a and 3c of - the algorithm so as to preserve the original flavor. - - In case the passage as suggested isn't clear enough, the intent is to - make "landing" at a wild card name and finding a CNAME the same as if - this happened as a result of a direct match. I.e., Finding a CNAME - at the name matched in step 3c is supposed to have the same impact as - finding the CNAME in step 3a. - -6.4. DNAME RR's at a Wild Card Domain Name - - The specification of the DNAME RR, which is at the proposed level of - standardization, is not as mature as the full standard in RFC 1034. - Because of this, or the reason for this is, there appears to be a - host of issues with that definition and it's rewrite of the algorithm - in 4.3.2. For the time being, when it comes to wild card processing - issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME - at a wild card domain name is effectively the same as a CNAME at a - wild card domain name. - - - - -Halley & Lewis [Expires March 2004] [Page 13] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -7. 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. - -8. References - - Normative References - - [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 - - [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, - Nov-01-1987 - - [RFC 1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - - [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S - Bradner, March 1997 - - Informative References - - [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, - Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 - - [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 - - [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 - -9. Others Contributing to This Document - - Others who have directly caused text to appear in the document: Paul - Vixie and Olaf Kolkman. Many others have indirect influences on the - content. - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 14] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -10. Editors - - Name: Bob Halley - Affiliation: Nominum, Inc. - Address: 2385 Bay Road, Redwood City, CA 94063 USA - Phone: +1-650-381-6016 - EMail: Bob.Halley@nominum.com - - Name: Edward Lewis - Affiliation: ARIN - Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA - Phone: +1-703-227-9854 - Email: edlewis@arin.net - - Comments on this document can be sent to the editors or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 15] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Appendix A: Subdomains of Wild Card Domain Names - - In reading the definition of section 2 carefully, it is possible to - rationalize unusual names as legal. In the example given, - *.example. could have subdomains of *.sub.*.example. and even the - more direct *.*.example. (The implication here is that these domain - names own explicit resource records sets.) Although defining these - names is not easy to justify, it is important that implementions - account for the possibility. This section will give some further - guidence on handling these names. - - The first thing to realize is that by all definitions, subdomains of - wild card domain names are legal. In analyzing them, one realizes - that they cause no harm by their existence. Because of this, they - are allowed to exist, i.e., there are no special case rules made to - disallow them. The reason for not preventing these names is that the - prevention would just introduce more code paths to put into - implementations. - - The concept of "closest enclosing" existing names is important to - keep in mind. It is also important to realize that a wild card - domain name can be a closest encloser of a query name. For example, - if *.*.example. is defined in a zone, and the query name is - a.*.example., then the closest enclosing domain name is *.example. - Keep in mind that the closest encloser is not eligible to be a source - of synthesized answers, just the subdomain of it that has the first - label "*". - - To illustrate this, the following chart shows some matches. Assume - that the names *.example., *.*.example., and *.sub.*.example. are - defined in the zone. - - QNAME Closest Encloser Wild Card Source - a.example. example. *.example. - b.a.example. example. *.example. - a.*.example. *.example. *.*.example. - b.a.*.example. *.example. *.*.example. - b.a.*.*.example. *.*.example. no wild card - a.sub.*.example. sub.*.example. *.sub.*.example. - b.a.sub.*.example. sub.*.example. *.sub.*.example. - a.*.sub.*.example. *.sub.*.example. no wild card - *.a.example. example. *.example. - a.sub.b.example. example. *.example. - - Recall that the closest encloser itself cannot be the wild card. - Therefore the match for b.a.*.*.example. has no applicable wild card. - - - - - -Halley & Lewis [Expires March 2004] [Page 16] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Finally, if a query name is sub.*.example., any answer available will - come from an exact name match for sub.*.example. No wild card - synthesis is performed in this case. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 17] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society 2003. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 18] diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt deleted file mode 100644 index e9943015..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt +++ /dev/null @@ -1,1120 +0,0 @@ - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: August 16, 2004 VeriSign - February 16, 2004 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This Internet-Draft describes DNS name server and resolver behavior - that results in a significant query volume sent to the root and - top-level domain (TLD) name servers. In some cases we recommend - minor additions to the DNS protocol specification and corresponding - changes in name server implementations 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. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Larson & Barber Expires August 16, 2004 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - document are to be interpreted as described in RFC 2119 [1]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Observed name server misbehavior . . . . . . . . . . . . . 4 - 2.1 Aggressive requerying for delegation information . . . . . 4 - 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5 - 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Inability to follow multiple levels of out-of-zone glue . 6 - 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7 - 2.4 Aggressive retransmission when fetching glue . . . . . . . 7 - 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8 - 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9 - 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10 - 2.7 Name server records with zero TTL . . . . . . . . . . . . 10 - 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11 - 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.9 Queries for domain names resembling IP addresses . . . . . 12 - 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12 - 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12 - 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 2.11 Suboptimal name server selection algorithm . . . . . . . . 13 - 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15 - 4. Security considerations . . . . . . . . . . . . . . . . . 16 - 5. Internationalization considerations . . . . . . . . . . . 17 - Normative References . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . 19 - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -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. - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient name server, stub - resolver and/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 glue records must be followed, and aggressive retry by stub - resolvers and/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. Some of the changes recommended affect the core DNS protocol - specification, described principally in RFC 1034 [2], RFC 1035 [3] - and RFC 2181 [4]. - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2. Observed name server 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 a recursive name server - 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 that 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. - - 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 recursive name server implementation immediately queries - a "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This name server - 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 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 a recursive name server 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 is pointless: this query to the parent would come so quickly - on the heels of the referral that it would be almost certain to - contain the same list of name servers. The chance of discovering any - new information is slim. - - The other possibility is that the recursive name server successfully - - - -Larson & Barber Expires August 16, 2004 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - 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 [4], 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 recursing name server 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 and/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, with servers that are 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. - -2.1.1 Recommendation - - Name servers offering recursion 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 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 [5]. - - -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 a subset of a zone's name servers being - unavailable or misconfigured. Different failure modes have different - expected durations. Some symptoms indicate problems that are - potentially transient: 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 - - - -Larson & Barber Expires August 16, 2004 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - 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. - -2.2.1 Recommendation - - Recursive name servers SHOULD cache name servers that they discover - are not authoritative for zones delegated to them (i.e. lame - servers). 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 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. - -2.3 Inability to follow multiple levels of out-of-zone glue - - Some recursive name server implementations are unable to follow more - than one level of out-of-zone glue. 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. - - A name server processing a recursive query for "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" and/or "ns2.test.example.net" in order to - obtain address records for "ns1.example.com" and/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 - - - -Larson & Barber Expires August 16, 2004 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - top-level domains (gTLDs) become active. We anticipate many zones in - the new gTLDs will use name servers in other gTLDs, increasing the - amount of inter-zone glue. - -2.3.1 Recommendation - - Clearly constructing a delegation that relies on multiple levels of - out-of-zone glue is not a good administrative practice. This issue - could be mitigated with an operational injunction in an RFC to - refrain from construction of such delegations. In our opinion the - practice is widespread enough to merit clarifications to the DNS - protocol specification to permit it on a limited basis. - - Name servers offering recursion SHOULD be able to handle at least - three levels of indirection resulting from out-of-zone glue. - -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 A records for every NS record in the - authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing A 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 a server will not - generate any queries of its own. Instead it answers non-recursive - queries from resolvers looking for information in zones it serves. - With glue fetching enabled, however, an authoritative server will - generate queries whenever it needs to look up an unknown address - record to complete the additional section of a response. - - We have observed situations where a glue-fetching name server can - send queries that reach other name servers, but apparently is - prevented from receiving the responses. For example, perhaps the - name server is authoritative-only and therefore its administrators - expect it to receive only queries. Perhaps unaware of glue fetching - and presuming that the name server will generate no queries, its - administrators place the name server behind a network device that - prevents it from receiving responses. If this is the case, all - glue-fetching queries will go answered. - - - -Larson & Barber Expires August 16, 2004 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - We have observed name server implementations that retry excessively - when glue-fetching queries are unanswered. A single com/net name - server has received hundreds of queries per second from a single name - server. 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, a - recursive name server 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 traffic is improperly - filtered in this manner. Stub resolvers in the organization could be - configured to query multiple name servers. Consider the case where a - stub resolver queries a filtered name server first. This name server - sends one or more queries whose replies are filtered, so it can't - respond to the stub resolver, which times out. The resolver - retransmits to a 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 has a very - aggressive retransmission schedule, including simultaneous queries to - multiple name servers, which could explain how such a situation could - persist without being detected. - -2.5.1 Recommendation - - - - -Larson & Barber Expires August 16, 2004 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - The most obvious recommendation is that administrators should take - care not to place recursive name servers behind a firewall that - prohibits queries to pass through but not the resulting replies. - - Name servers 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. A recursive name server - attempting to resolve A 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 - information is correct in the "com" zone.) The recursive name server - 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" A record in the answer section - and, typically, the "example.com" NS records in the authority section - and, if space in the message remains, glue A records in the - additional section. According to Section 5.4 of RFC 2181 [4], 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 displaces the - "example.com" NS RRset received moments ago from the "com" - 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 server to attempt to use the incorrect NS records and - so the server will try to resolve the nonexistent names - - - -Larson & Barber Expires August 16, 2004 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - "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 recursive server cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in A - record queries to the "com' authoritative servers. Queries for such - obviously bogus glue A 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 is in the zone. But any in-zone name server - should have a corresponding glue A record also in the zone. An - authoritative name server should report an error when a zone's NS - record references an in-zone name server without a corresponding glue - A record. - -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 a recursive name - server 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 - 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 recursive name servers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - - - -Larson & Barber Expires August 16, 2004 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2.7.1 Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers imposed by a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers should issue a - warning when loading a zone or refuse to load the zone altogether. - -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 - is the lowest zone in the name space. The closest enclosing zone - 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 involves working up the name - space tree and sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an A 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 reasonable question is why the algorithm proceeds with - sending updates all the way to TLD and root name servers. In - enterprise DNS architectures with an "internal root" design, there - could conceivably be private, non-public TLD or root zones that would - be the appropriate target for a dynamic update. However, we question - if designing an algorithm to accommodate these limited cases is worth - the load it places on the public DNS in the form of unnecessary - UPDATE messages. - -2.8.1 Recommendation - - Dynamic update agents should not attempt to send UPDATE messages to - authoritative servers for TLD zones or the root zone by default. If - this functionality is supported, it should be require specific action - - - -Larson & Barber Expires August 16, 2004 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - by a user to be enabled. - -2.9 Queries for domain names resembling IP addresses - - The root name servers receive a significant number of A record - queries where the qname is an IP 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. A recursive - name server 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 - bandwidth. One possibility is for recursive name server - implementations to produce the Name Error response directly. We - suggest that implementors consider the option of synthesizing Name - Error responses at the recursive name server. The server could claim - authority for synthesized TLD zones corresponding to the first octet - of every possible IP address, e.g. 1., 2., through 255. This - behavior could be configurable in the (probably unlikely) event that - numeric TLDs are ever put into use. - - Another option is to delegate these numeric TLDs from the root zone - to a separate set of servers to absorb the traffic. The "blackhole - servers" used by the 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. - -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 offer 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 - - - -Larson & Barber Expires August 16, 2004 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - 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 (supposedly) recursive name server is - configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server - supports recursion (i.e., 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 underspecified, 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. - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by a recursive name server. When a recursive name server - 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. - - - - -Larson & Barber Expires August 16, 2004 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - 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. - 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. A - recursive name server 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 August 16, 2004 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -3. IANA considerations - - There are no new IANA considerations introduced by this - Internet-Draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -4. Security considerations - - Name server and resolver misbehaviors identical or similar to those - discussed in this document expose the root and TLD name servers to - increased risk of both intentional and unintentional denial of - service. - - 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 August 16, 2004 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -5. Internationalization considerations - - We do not believe this document introduces any new - internationalization considerations to the DNS protocol - specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Normative 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] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - 2308, March 1998. - - [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 - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: pbarber@verisign.com - - - - - -Larson & Barber Expires August 16, 2004 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Larson & Barber Expires August 16, 2004 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 20] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt deleted file mode 100644 index 0481517..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt +++ /dev/null @@ -1,1344 +0,0 @@ -
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: August 30, 2004 R. Gieben
- NLnet Labs
- March 2004
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-01.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- 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 30, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document describes a set of practices for operating a DNSSEC
- aware environment. The target audience is zone administrators
- deploying DNSSEC that need a guide to help them chose appropriate
- values for DNSSEC parameters. It also discusses operational matters
- such as key rollovers, KSK and ZSK considerations and related
- matters.
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 1]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3
- 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3
- 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5
- 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7
- 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8
- 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8
- 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8
- 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9
- 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
- 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13
- 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14
- 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
- 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
- 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16
- 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16
- 5.1 Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . . . 16
- 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16
- 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17
- 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
- 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
- B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20
- C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20
- D. Document Details and Changes . . . . . . . . . . . . . . . . . 22
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22
- D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 2]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- and system administrators gained experience about operating DNSSEC
- aware DNS services. 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 represented '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: It begins with
- discussing some of the considerations with respect to timing
- parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
- management such as key rollover schemes are described in Section 3.
- Emergency rollover considerations are addressed in Section 4. 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 [5] language does not apply.
-
-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
- [Ref to Schneider?]). 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
- used in key-exchanges.
-
-1.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, which may cause
- entire (sub)domains to become invisible to verifying clients. The
- administrators of secured zones have to realise 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,
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 3]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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, during which
- period clients may be fetching data from caching non-authoritative
- servers. For the verifying clients it is important that data from
- secured 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 the fact that the key has been
- stolen, must be made.
-
- The zone administrator will have to make a tradeoff between keeping
- the chain of trust intact -thereby allowing for attacks with the
- compromised key- or to deliberately break the chain of trust thereby
- making secured subdomains invisible to security aware resolvers. Also
- see Section 4.
-
-2. Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA's refresh,
- retry and expiration timers are counters that are used to determine
- the time elapsed after a slave server syncronised (or tried to
- syncronise) with a master server. The Time to Live (TTL) value and
- the SOA minimum TTL parameter [6] are used to determine how long a
- forwarder should cache data after it has been fetched from an
- authoritative server. 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.
-
-2.1 Time Definitions
-
- In this document we will be using a number of time related terms.
- Within the context of this document 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.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 4]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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. If a signature is published at time T0 and a
- new signature is published at time T1, the signature
- publication period is T1 - T0.
- If all signatures are refreshed at zone (re)signing then the
- signature publication period is equal signature validity
- period.
- o "Maximum/Minimum Zone TTL"
- The maximum or minimum value of all the TTLs in a zone.
-
-2.2 Time Considerations
-
- Because of the expiration of signatures, one should consider the
- following.
- o The Maximum Zone TTL of your zone data should 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. As a
- result query load on authoritative servers would peak at
- signature expiration time.
- 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 The signature publication period should 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 The Minimum zone TTL should be long enough to both fetch and
- verify all the RRs in the authentication chain.
- 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 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.
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 5]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- We have seen events where data needed for verification of an
- authentication chain had expired from caches.
- We suggest the TTL on DNSKEY and DSs to be between ten minutes
- and one hour. We recommend zone administrators to chose TTLs
- longer than half a minute.
- [Editor's Note: this observation could be implementation
- specific. We are not sure if we should leave this item]
- o Slave servers will need to be able to fetch newly signed zones
- well before the data expires from your zone.
- 'Better no answers than bad answers.'
- If a properly implemented slave server is not able to contact a
- master server for an extended period the data will at some
- point expire and the slave server will not hand out any data.
- 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 signaturs, is
- that non-secure resolvers will continue to be able to resolve
- data served by the particular slave servers. Security aware
- resolvers will experience problems.
- 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 suggest that operators of nameservers with slave zones
- develop 'watch dogs' to spot upcoming signature expirations in
- slave zones, 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 and load a valid zone? All these arguments are
- not DNSSEC specific.
-
-3. Keys
-
- In the DNSSEC protocol there is only one type of key, the zone key.
- With this key, the data in a zone is signed.
-
- To make zone re-signing and key rollovers 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 RRs 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 parents
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 6]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- and potentially for configuration as trusted anchors - the so called
- Secure Entry Point keys (SEP). In this document we assume a
- one-to-one mapping between KSK and SEP keys and we assume the SEP
- flag [4] to be set on KSKs.
-
-3.1 Motivations for the KSK and ZSK Functions
-
- Differentiating between the KSK to ZSK functions has several
- advantages:
-
- o Making the KSK stronger (i.e. using more bits in the key material)
- has little operational impact since it is only used to sign a
- small fraction of the zone data.
- o As the KSK is only used to sign a keyset, which is most probably
- updated less frequently than other data in the zone, it can be
- stored separately from (and thus in a safer location than) the
- ZSK.
- o A KSK can be used for longer periods.
- o No parent/child interaction is required when ZSKs are updated.
-
- The KSK is used less than ZSK, once a keyset is signed with the KSK
- all the keys in the keyset can be used as ZSK. If a ZSK is
- compromised, it can be simply dropped from the keyset. The new keyset
- 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 e.g. a value of 256 and a key signing key has 257.
-
- 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 relatively
- short "Signature Validity Periods". That is, Signature Validity
- Periods of the order of days.
-
- The key-signing key is only to be used to sign the Key RR set from
- the zone apex. If a key-signing key is to be rolled over, there will
- be interactions with parties other than the zone administrator such
- as the registry of the parent zone or administrators of verifying
- resolvers that have the particular key configured as trusted entry
- points. Hence, the "Key Usage Time" 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 to plan for a "Key
- Usage Time" of the order of a few months so that a key rollover
- remains an operational routine.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 7]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-3.2 Key Security Considerations
-
- Keys in DNSSEC have a number of parameters which should all be chosen
- with care, the most important once are: size, algorithm and the key
- validity period (its lifetime).
-
-3.2.1 Key Validity Period
-
- RFC2541 [2] describes a number of considerations with respect to the
- security of keys. The document deals with the generation, lifetime,
- size and storage of private keys.
-
- In Section 3 of RFC2541 [2] there are some suggestions for a key
- validity period: 13 months for long-lived keys and 36 days for
- transaction keys but suggestions for key sizes are not made.
-
- If we say long-lived keys are key-signing keys and transactions keys
- are zone-signing keys, 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
- replaced.
-
-3.2.2 Key Algorithm
-
- We recommend you choose RSA/SHA-1 as the preferred algorithm for the
- key. RSA has been developed in an open and transparent manner. As the
- patent on RSA expired in 2001, its use is now also free. 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.
-
-3.2.3 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 [9] 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 cryptosystems. For
- details we refer to the original paper.
-
- [Editor's Note: DSA???]
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 8]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- Year RSA Key Sizes Elliptic Curve Key Size
- 2000 952 132
- 2001 990 135
- 2002 1028 139
- 2003 1068 140
- 2004 1108 143
-
- 2005 1149 147
- 2006 1191 148
- 2007 1235 152
- 2008 1279 155
- 2009 1323 157
-
-
- 2010 1369 160
- 2011 1416 163
- 2012 1464 165
- 2013 1513 168
- 2014 1562 172
-
- 2015 1613 173
- 2016 1664 177
- 2017 1717 180
- 2018 1771 181
- 2019 1825 185
-
-
- 2020 1881 188
- 2021 1937 190
- 2022 1995 193
- 2023 2054 197
- 2024 2113 198
-
- 2025 2174 202
- 2026 2236 205
- 2027 2299 207
- 2028 2362 210
- 2029 2427 213
-
- For example, should you wish your key to last three years from 2003,
- check the RSA keysize values for 2006 in this table. In this case
- 1191.
-
-3.3 Key Rollovers
-
- Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
- cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
- administrators who are in the process of rolling their keys have to
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 9]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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.
-
- To appreciate the situation one could think of a number of
- authoritative servers that may not be instantaneously running the
- same version of a zone and a security aware non-recursive resolver
- that sits behind security aware caching forwarders.
-
- Note that KSK rollovers and ZSK rollovers are different. A zone-key
- rollover can be handled in two different ways: pre-publish (Section
- Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The
- pre-publish technique works because the key-signing key stays the
- same during this ZSK rollover. With this KSK a cache is able to
- validate the new keyset of a zone. With a KSK rollover a cache can
- not validate the new keyset, because it does not trust the new KSK.
-
- [Editors note: This needs more verbose explanation, nobody will
- appreciate the situation just yet. Help with text and examples is
- appreciated]
-
-3.3.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
- keysets or newly generated signatures can be verified with the keys
- still in caches. One schema uses double signatures, it is described
- in Section 3.3.1.2, the other uses key pre-publication (Section
- 3.3.1.1). The pros, cons and recommendations are described in Section
- 3.3.1.3.
-
-3.3.1.1 Pre-publish Keyset 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 "prepublish
- rollover". We recommend this method because it has advantages in the
- case of 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
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 10]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 keyset. 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
- keyset. This equates to two times the Maximum Zone TTL.
- roll: At the rollover stage (SOA serial 1) 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 keyset. 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 keyset 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 keyset, now only
- containing 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 August 30, 2004 [Page 11]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- normal roll after 2nd roll 2nd after
-
- SOA0 SOA2 SOA3 SOA4 SOA5
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
- DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(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.
-
- This scheme has the benefit that the key that is intended for future
- use: immediately during an emergency rollover assuming that the
- private key was stored in a physically secure manner.
-
-3.3.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, this will take at least the
- maximum Zone TTL .
-
- 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.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 12]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the keyset 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 keyset, now only
- containing DNSKEY 11, is resigned with DNSKEY 1.
-
- At every instance the data from the previous version of the zone can
- be verified with the key from the current version and vice verse. 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.
- 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.
-
-3.3.1.3 Pros and Cons of the Schemes
-
- Prepublish-keyset rollover: This rollover does not involve signing
- the zone data twice. Instead, just before the actual rollover, the
- new key is published in the keyset and thus available for
- cryptanalysis attacks. A small disavantage is that this process
- requires four steps. Also the prepublish scheme will not work for
- KSKs as explained in Section 3.3.
- 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.
-
-3.3.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 keyset) in
- caches can be verified with a new keyset and vice versa.
-
- Since only the keyset is signed with a KSK, zone size considerations
- do not apply.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 13]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 parents zone, the zone administrator
- has to wait at least TTL_DS to make sure that the old DS RR has
- expired from distant caches.
- 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. St John [The
- draft has expired] proposed a mechanism where using an established
- trust relation, the interaction can be performed in-band. In this
- mechanism there are periods where there are two DS RRs at the parent.
-
- [Editors note: We probably need to mention more]
-
-4. 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.
-
- [Editors note: We are much in favor of a rollover tactic that keeps
- the authentication chain intact as long as possible. This means that
- one has to take all the regular rollover properties into account.]
-
- 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:
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 14]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 the hardest to update.)
- While an authentication chain to your compromised key exists, your
- name-space is vulnerable to abuse by the malicious key holder (i.e.
- the owner of the compromised key). Zone operators have to make a
- 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 will usually be localised in the
- Internet topology.
-
-
-4.1 KSK Compromise
-
- When the KSK has been compromised the parent must be notified as soon
- as possible using secure means. The keyset 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 been updated with 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 out of band and secure notify mechanism to contact a
- parent is needed in this case.
-
-4.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 minimises such problems.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 15]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-4.3 Compromises of Keys Anchored in Resolvers
-
- A key can also be pre-configured in resolvers. If DNSSEC is rolled
- out as planned the root key should be pre-configured in every secure
- aware resolver on the planet. [Editors Note: add more about
- authentication of a newly received resolver key]
-
- If trust-anchor keys are compromised, the resolvers using these keys
- 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.
-
-5. Parental Policies
-
-5.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 authorisation
- mechanisms used during a key exchange should be as strong as the
- authentication and authorisation mechanisms used for the exchange of
- delegation information between parent and child.
-
- 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 [4] to select the proper key from a
- DNSSEC keyset; 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 child will not become bogus 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 by a tool. The parent can not be sure whether the DNSKEY
- RRs have been spoofed.
-
-5.2 Storing Keys So Hashes Can Be Regenerated
-
- When designing a registry system one should consider if the DNSKEYs
- and/or the corresponding DSs are stored. Storing DNSKEYs will help
- during troubleshooting while the overhead of calculating 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 may also help with troubleshooting.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 16]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-5.3 Security Lameness Checks
-
- Security Lameness is defined as what happens when a parent has a DS
- Resource Record 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 would render 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. by removing a DS RR) will
- take time to propagate through the DNS.
-
-5.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 minimises 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
- lifetimes longer than 2 days. We recommend the minimum for a DS
- signature validity period to be a few days.
-
- The maximum signature lifetime of the DS record depends on how long
- child zones are willing to be vulnerable after a key compromise. We
- consider a signature validity period of around one week to be a good
- compromise between the operational constraints of the parent and
- minimising damage for the child.
-
-6. Security Considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- considerations to operate 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.
-
-7. Acknowledgments
-
- We, the folk mentioned as authors, only acted as editors. 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 where the original
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 17]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- contributors of the ideas we would like to acknowledge people who
- where actively involved in the compilation of this document. In
- random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
- Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
- Courtay, Sam Weiler.
-
- Emma Bretherick and Adrian Bedford corrected many of the spelling and
- style issues.
-
- Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-8. References
-
-8.1 Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
- (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
- in progress), February 2003.
-
-8.2 Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
- 2308, March 1998.
-
- [7] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-13 (work in progress), March
- 2003.
-
- [8] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
- progress), March 2003.
-
- [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
- The Journal of Cryptology 14 (255-293), 2001.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 18]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-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.
-
- 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 i.e. should not be
- exposed to parties not-authorised to do the actual signing.
- 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.
- KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
- signing the apex keyset. The fact that a key is a KSK is only
- relevant to the signing tool.
- 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.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 19]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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.
- Anchored Key: A DNSKEY configured in resolvers around the globe. This
- Key is hard to update, hence the term anchored.
- Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked
- "Bogus" when a signature of a RRset does not validate against the
- DNSKEY. Even if the key itself was not marked Bogus. A cache may
- choose to cache Bogus data for various reasons.
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
- 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 distant caches
- here follows the "HOWTO". [WES: has some comments about this]
- Key notation:
- Step 0: The preparation: Create two keys and publish both in your
- keyset. 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.
- 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.
- 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.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 20]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- 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 :
-
-
- example.net. 600 IN SOA ns.example.net. ernie.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 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
- 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.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 21]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following represenation:
-
- 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.
-
- $Header: /var/cvs/dnssec-key/
- draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12
- 08:29:11 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
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 22]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 23]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 24]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt deleted file mode 100644 index 42c3c0b..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt +++ /dev/null @@ -1,1321 +0,0 @@ - -DNS Operations WG -Internet-Draft J. Jeong (ed.) - ETRI - -Expires: January 2005 18 July 2004 - - - IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-02.txt - - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which we become aware will be disclosed, in accordance - with RFC3668. - - 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 17, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational - attributes of three solutions: RA option, DHCPv6 option, and Well- - known anycast addresses for recursive DNS servers. Additionally, - it suggests four deployment scenarios considering multi-solution - resolution. Therefore, this document will give the audience a - - - -Jeong, et al. Expires - January 2005 [Page 1] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - guideline of IPv6 DNS configuration to select approaches suitable - for their host DNS configuration. - -Table of Contents - - 1. Introduction...................................................3 - 2. Terminology....................................................3 - 3. IPv6 DNS Configuration Approaches..............................3 - 3.1 RA Option..................................................3 - 3.1.1 Advantages...........................................4 - 3.1.2 Disadvantages........................................5 - 3.1.3 Observations.........................................5 - 3.2 DHCPv6 Option..............................................6 - 3.2.1 Advantages...........................................7 - 3.2.2 Disadvantages........................................8 - 3.2.3 Observations.........................................9 - 3.3 Well-known Anycast Addresses...............................9 - 3.3.1 Advantages...........................................9 - 3.3.2 Disadvantages.......................................10 - 3.3.3 Observations........................................10 - 4. Interworking among IPv6 DNS Configuration Approaches..........11 - 5. Deployment Scenarios..........................................12 - 5.1 ISP Network...............................................12 - 5.1.1 RA Option Approach..................................12 - 5.1.2 DHCPv6 Option Approach..............................13 - 5.1.3 Well-known Addresses Approach.......................13 - 5.2 Enterprise Network........................................14 - 5.3 3GPP Network..............................................14 - 5.3.1 Currently Available Mechanisms and Recommendations..15 - 5.3.2 RA Extension........................................16 - 5.3.3 Stateless DHCPv6....................................16 - 5.3.4 Well-known Addresses................................17 - 5.3.5 Recommendations.....................................17 - 5.4 Unmanaged Network.........................................18 - 5.4.1 Case A: Gateway does not provide IPv6 at all........18 - 5.4.2 Case B: A dual-stack gateway connected to a dual-stack - ISP.........................................18 - 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only - ISP.........................................19 - 5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19 - 6. Security Considerations.......................................19 - 7. Acknowledgements..............................................19 - 8. Normative References..........................................20 - 9. Informative References........................................20 - 10. Authors' Addresses...........................................21 - Intellectual Property Statement..................................23 - Full Copyright Statement.........................................23 - Acknowledgement..................................................24 - - -Jeong, et al. Expires - January 2005 [Page 2] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide ways to configure either fixed or mobile - nodes with one or more IPv6 addresses, default routes and some - other parameters [3][4]. To support access to additional services - in the Internet that are identified by a DNS name, such as a web - server, the configuration of at least one recursive DNS server is - also needed for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 - option [5]-[7], and (c) Well-known anycast addresses for recursive - DNS servers [9]. Also, it suggests applicable scenarios for four - kinds of networks: (a) ISP network, (b) Enterprise network, (c) - 3GPP network, and (d) Unmanaged network. - - This document is just an analysis of each possible approach, and - does not make any recommendation on particular one or on a - combination of particular ones. Some approaches may even not be - adopted at all as a result of further discussion. - - Therefore, the objective of this document is to help the audience - select approaches suitable for IPv6 host configuration of recursive - DNS server. - -2. Terminology - - This document uses the terminology described in [3]-[9]. In - addition, a new term is defined below: - - Recursive DNS Server (RDNSS) A Recursive DNS Server is a name - server that offers the recursive - service of DNS name resolution. - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of three solutions are - described in detail. - -3.1 RA Option - - RA approach is to define a new ND option called RDNSS option that - contains a recursive DNS server address. Existing ND transport - mechanisms (i.e., advertisements and solicitations) are used. This - works in the same way that nodes learn about routers and prefixes, - etc. An IPv6 host can configure the IPv6 addresses of one or more - - -Jeong, et al. Expires - January 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - RDNSSes via RA message periodically sent by router or solicited by - a Router Solicitation (RS) [8]. This approach needs RDNSS - information to be configured in the routers doing the - advertisements. The configuration of RDNSS address can be - performed manually by operator or other ways, such as automatic - configuration through DHCPv6 client running on the router. When - advertising more than one RDNSS options, an RA message includes as - many RDNSS options as RDNSSes. Through ND protocol and RDNSS - option along with prefix information option, an IPv6 host can - perform its network configuration of its IPv6 address and RDNSS - simultaneously [3][4]. The RA option for RDNSS can be used on any - network that supports the use of ND. However, RA approach performs - poorly in some wireless environments where RA message is used for - IPv6 address autoconfiguration, such as WLAN networks. - - The RA approach is useful in some non-WLAN mobile environments - where the addresses of the RDNSSes are changing because the RA - option includes a lifetime field. This can be configured to a - value that will require the client to time out the entry and switch - over to another RDNSS address [8]. However, from the viewpoint of - implementation, lifetime would seem to make matters a bit more - complex. Instead of just writing DNS configuration file, such as - resolv.conf for the list of RDNSS addresses, we have to have a - daemon around (or a program that is called at the defined - intervals) that keeps monitoring the lifetime of RDNSSes all the - time. - - The preference value of RDNSS, included in RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes; this can - be used for load balancing of RDNSSes [8]. - -3.1.1 Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1) The RA option is an extension of existing ND/Autoconfig - mechanisms [3][4], and does not require a change in the base ND - protocol. - - 2) This approach, like ND, works well on a variety of link types - including point-to-point links, point-to-multipoint, and multi- - point (i.e., Ethernet LANs), etc. RFC2461 [3] states, however, - that there may be some link type on which ND is not possible; on - such a link, some other mechanism will be needed for DNS - configuration. - - 3) All of the information a host needs to run basic Internet - applications such as email, the web, ftp, etc., can be performed - - -Jeong, et al. Expires - January 2005 [Page 4] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - with the addition of this option to ND and address auto- - configuration. The use of a single mechanism is more reliable and - easier to provide than when the RDNSS information is learned via - another protocol mechanism. Debugging problems when multiple - protocol mechanisms are being used is harder and much more complex. - - 4) This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that support broadcast - reliably (e.g., Ethernet LANs) but not necessarily on other links - (e.g., Wireless LANs). Also, this works well on links that are - high performance (e.g., Ethernet LANs) and low performance (e.g., - Cellular networks). In the latter case, combining the RDNSS - information with the other information in the RA, the host can - learn all of the information needed to use most Internet - applications such as the web in a single packet. This not only - saves bandwidth where this is an issue, but also minimizes the - delay to learn the RDNSS information. - - 5) The RA approach could be used as a model for other similar types - of configuration information. New RA options for other server - addresses that are common to all clients on a subnet would be easy - to define. This includes things like NTP servers, SIP servers, etc. - -3.1.2 Disadvantages - - 1) ND is mostly implemented in kernel part of operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS, NTP and SIP servers, ND should be extended - in kernel part. DHCPv6, however, has more flexibility for - extension of service discovery because it is an application layer - protocol. - - 2) The current ND framework should be modified due to the - synchronization between another ND cache for RDNSSes in kernel - space and DNS configuration file in user space. Because it is - unacceptable to write and rewrite the DNS configuration file (e.g., - resolv.conf) from the kernel, another approach is needed. One - simple approach to solve this is to have a daemon listening to what - the kernel conveys, and to have the daemon do these steps, but such - a daemon is not necessary with the current ND framework. - - 3) It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be configured - by RA option. - -3.1.3 Observations - - - - -Jeong, et al. Expires - January 2005 [Page 5] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The proposed RDNSS RA option along with IPv6 ND and Auto- - configuration allows a host to obtain all of the information it - needs to access basic Internet services like the web, email, ftp, - etc. This is preferable in environments where hosts use RAs to - autoconfigure their addresses and all hosts on the subnet share the - same router and server addresses. If the configuration information - can be obtained from a single mechanism, it is preferable because - it does not add additional delay, and it uses a minimum of - bandwidth. Environments like this include homes, public cellular - networks, and enterprise environments where no per host - configuration is needed, but exclude public WLAN hot spots. - - DHCPv6 is preferable where it is being used for address - configuration and if there is a need for host specific - configuration [5]-[7]. Environments like this are most likely - enterprise environments where the local administration chooses to - have per host configuration control. - - Note: the observation section is based on what the proponents of - each approach think makes a good overall solution. - -3.2 DHCPv6 Option - - DHCPv6 [5] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - servers [7]. The DNS Recursive Name Server option carries a list - of IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by - the DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information- - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as - stateless DHCPv6 [6]. - - Stateless DHCPv6 can be deployed either using DHCPv6 servers - running on general-purpose computers, or on router hardware. - Several router vendors currently implement stateless DHCPv6 servers. - Deploying stateless DHCPv6 in routers has the advantage that no - special hardware is required, and should work well for networks - where DHCPv6 is needed for very straightforward configuration of - network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router - it can be on a - general purpose computer. This has the potential to give the - - -Jeong, et al. Expires - January 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - operator of the DHCPv6 server more flexibility in how the DHCPv6 - server responds to individual clients - clients can easily be given - different configuration information based on their identity, or for - any other reason. Nothing precludes adding this flexibility to a - router, but generally in current practice, DHCP servers running on - general-purpose hosts tend to have more configuration options than - those that are embedded in routers. - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. Using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group is currently studying an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The Lifetime Option for DHCPv6 [10], - assigns a lifetime to configuration information obtained through - DHCPv6. At the expiration of the lifetime, the host contacts the - DHCPv6 server to obtain updated configuration information, - including the list of RDNSSes. This lifetime gives the network - administrator another mechanism to configure hosts with new RDNSSes - by controlling the time at which the host refreshes the list. - - The DHC Working Group has also discussed the possibility of - defining an extension to DHCPv6 that would allow the use of - multicast to provide configuration information to multiple hosts - with a single DHCPv6 message. Because of the lack of deployment - experience, the WG has deferred consideration of multicast DHCPv6 - configuration at this time. Experience with DHCPv4 has not - identified a requirement for multicast message delivery, even in - large service provider networks with tens of thousands of hosts - that may initiate a DHCPv4 message exchange simultaneously. - -3.2.1 Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1) DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. So configuring - DHCPv6 servers allows the network administrator to configure - RDNSSes along with the addresses of other network services, as well - as location-specific information like time zones. - - - -Jeong, et al. Expires - January 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - 2) As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be managed - through a single service, typically with a single user interface - and a single configuration database. - - 3) DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes as well as other configuration - information. This capability is important in some network - deployments such as service provider networks or WiFi hot spots. - - 4) A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5) Hosts that require other configuration information such as the - addresses of SIP servers and NTP servers are likely to need DHCPv6 - for other configuration information. - - 6) The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions such as new - options are necessary. - - 7) Interoperability among independent implementations has been - demonstrated. - -3.2.2 Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These - include: - - 1) Update currently requires message from server (however, see - [10]). - - 2) Because DNS information is not contained in RA message, the host - must receive two messages from the router, and must transmit at - least one message to the router. On networks where bandwidth is at - a premium, this is a disadvantage, although on most networks it is - not a practical concern. - - 3) Increased latency for initial configuration - in addition to - waiting for an RA message, the client must now exchange packets - with a DHCPv6 server; even if it is locally installed on a router, - this will slightly extend the time required to configure the client. - For clients that are moving rapidly from one network to another, - this will be a disadvantage. - - - - -Jeong, et al. Expires - January 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - -3.2.3 Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in - addition to a list of RDNSSes or if hosts must be configured - selectively, those hosts will use DHCPv6 and the use of the DHCPv6 - DNS recursive name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, on a cell phone network, where bandwidth is at a premium - and extremely low latency is desired. The final DNS configuration - draft should be written so as to allow these special applications - to be handled using DNS information in the RA packet. - -3.3 Well-known Anycast Addresses - - First of all, the well-known anycast addresses approach is much - different from that discussed in IPv6 Working Group in the past. - - The approach with well-known anycast addresses is to set well-known - anycast addresses in clients' resolver configuration files from the - beginning, say, as factory default. Thus, there is no transport - mechanism and no packet format [9]. - - An anycast address is an address shared by multiple servers (in - this case, the servers are RDNSSes). Request from a client to the - anycast address is routed to a server selected by the routing - system. However, it is a bad idea to mandate "site" boundary on - anycast addresses, because most users just do not have their own - servers and want to access their ISPs' across their site boundaries. - Larger sites may also depend on their ISPs or may have their own - RDNSSes within "site" boundaries. - - It should be noted that "anycast" in this memo is simpler than that - of RFC1546 [11] and RFC3513 [12] where it is assumed to be - prohibited to have multiple servers on a single link sharing an - anycast address. That is, on a link, anycast address is assumed to - be unique. DNS clients today already have redundancy by having - multiple well-known anycast addresses configured as RDNSS addresses. - There is no point to have multiple RDNSSes sharing an anycast - address on a single link. - -3.3.1 Advantages - - - - -Jeong, et al. Expires - January 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, - 1) There is no delay to get response and no further delay by packet - losses. - - 2) The approach can be combined with any other configuration - mechanisms including but not limited to factory default - configuration, RA-based approach and DHCP based approach. - - 3) The approach works over any environment where DNS works. - - Another advantage is that the approach needs to configure DNS - servers as a router, but nothing else. Considering that DNS - servers do need configuration, the amount of overall configuration - effort is proportional to the number of the DNS servers and scales - linearly. It should be noted that, in the simplest case where a - subscriber to an ISP does not have any DNS server, the subscriber - naturally access DNS servers of the ISP even though the subscriber - and the ISP do nothing and there is no protocol to exchange DNS - server information between the subscriber and the ISP. - -3.3.2 Disadvantages - - Well-known anycast addresses approach requires that DNS servers (or - routers near it as a proxy) act as routers to advertise their - anycast addresses to the routing system, which requires some - configuration (see the last paragraph of the previous section on - the scalability of the effort). - -3.3.3 Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce configuration effort of users. - - Redundancy by multiple RDNSSes is better provided by multiple - servers having different anycast addresses than multiple servers - sharing same anycast address because the former approach allows - stale servers to still generate routes to their anycast addresses. - Thus, in a routing domain (or domains sharing DNS servers), there - will be only one server having an anycast address unless the domain - is so large that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address which is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, - where boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - - -Jeong, et al. Expires - January 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be - able to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC1546 [11] - and RFC3513 [12] where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related - instability disappears. Thus, anycast in well-known anycast - addresses approach can and should use the anycast address as a - source unicast (according to RFC3513 [12]) address of packets of - UDP and TCP responses. With TCP, if route flips and packets to an - anycast address are routed to a new server, it is expected that the - flip is detected by ICMP or sequence number inconsistency and the - TCP connection is reset and retried. - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork each other. - - For ordering between RA and DHCP approaches, O (Other stateful - configuration) flag in RA message can be used [8]. If no RDNSS - option is included, an IPv6 Host may perform DNS configuration - through DHCPv6 [5]-[7] regardless of whether the O flag is set or - not. - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove - configuration effort on servers by using the well-known addresses - as the default configuration. Moreover, clients preconfigured with - well-known anycast addresses can be further configured to use other - approaches to override the well-known addresses, if configuration - information from other approaches are available. That is, all the - clients should have the well-known anycast addresses preconfigured, - in the case where there are no other mechanisms available. In - order to fly anycast approach with the other solutions, there are - three options. - - The first option is that well-known addresses are used as last - resort, when an IPv6 host can not get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be pre- - configured in IPv6 hosts' resolver configuration files. - - - - - -Jeong, et al. Expires - January 2005 [Page 11] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The second is that an IPv6 host can configure well-known addresses - as the most preferable in its configuration file even though either - RA option or DHCP option is available. - - The last is that the well-known anycast addresses can be set in RA - or DHCP configuration to reduce configuration effort of users. - According to either RA or DHCP mechanism, the well-known addresses - can be obtained by IPv6 host. Because this approach is the most - convenient for users, the last option is recommended. - - Note: this section does not necessarily mean this document suggests - adopting all these three approaches and making them interwork in - the way described here. In fact, some approaches may even not be - adopted at all as a result of further discussion. - -5. Deployment Scenarios - - Regarding DNS configuration on the IPv6 host, several mechanisms - have being considered at the DNSOP Working Group such as RA option, - DHCPv6 option and well-known preconfigured anycast addresses as of - today, and this document is a final result from the long thread. - In this section, we suggest four applicable scenarios of three - approaches for IPv6 DNS configuration. - - Note: in the applicable scenarios, authors do not implicitly push - any specific approaches into the restricted environments. No - enforcement is in each scenario and all mentioned scenarios are - probable. The main objective of this work is to provide a useful - guideline of IPv6 DNS configuration. - -5.1 ISP Network - - A characteristic of ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and each PE connects multiple CPE devices to the backbone - network infrastructure [13]. The CPEs may be hosts or routers. - - In the case where the CPE is a router, there is a customer network - that is connected to the ISP backbone through the CPE. Typically, - each customer network gets a different IPv6 prefix from an IPv6 PE - router, but the same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1 RA Option Approach - - - - -Jeong, et al. Expires - January 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - When the CPE is a host, the RA option for RDNSS can be used to - allow the CPE to get RDNSS information as well as /64 prefix - information for stateless address autoconfiguration at the same - time when the host is attached to a new subnet [8]. Because an - IPv6 host must receive at least one RA message for stateless - address autoconfiguration and router configuration, the host could - receive RDNSS configuration information in that RA without the - overhead of an additional message exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP, and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in - which the host must receive at least an RA message for detecting a - new network, than in other scenarios generally although - administrator should configure RDNSS information on the routers. - Secure ND [14] can provide extended security when using RA message. - -5.1.2 DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the - DNS option, and can provide other configuration information in the - same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option - is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6- - lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISP can - handle user identification on its network intentionally, and also - authenticated DHCP [15] can be used for secure message exchange. - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the - customer gateway to assign a /64 prefix to each network in the - customer's network. Prefix delegation with DHCP (DHCPv6 PD) has - already been adopted by ISPs for automating the assignment of the - customer prefix to the customer gateway [17]. DNS configuration - can be carried in the same DHCPv6 message exchange used for DHCPv6 - to efficiently provide that information, along with any other - configuration information needed by the customer gateway or - customer network. This service model can be useful to Home or SOHO - subscribers. The Home or SOHO gateway, which is a customer gateway - for ISP, can then pass that RDNSS configuration information to the - hosts in the customer network through DHCP. - -5.1.3 Well-known Addresses Approach - - Well-known anycast addresses approach is also a feasible and simple - mechanism for ISP [9]. The use of well-known anycast addresses - - -Jeong, et al. Expires - January 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - avoids some of the security risks in rogue messages sent through an - external protocol like RA or DHCPv6. The configuration of hosts - for the use of well-known anycast addresses requires no protocol or - manual configuration, but the configuration of routing for the - anycast addresses requires intervention on the part of the network - administrator. Also, the number of special addresses would be - equal to the number of RDNSSes that could be made available to - subscribers. - -5.2 Enterprise Network - - Enterprise network is defined as a network that has multiple - internal links, one or more router connections, to one or more - Providers and is actively managed by a network operations entity - [16]. An enterprise network can get network prefixes from ISP by - either manual configuration or prefix delegation [17]. In most - cases, because an enterprise network manages its own DNS domains, - it operates its own DNS servers for the domains. These DNS servers - within enterprise network process recursive DNS name resolution - requests of IPv6 hosts as RDNSS. RDNSS configuration in enterprise - network can be performed like in Section 4, in which three - approaches can be used together. - - IPv6 host can decide which approach is or may be used in its subnet - with O flag in RA message [8]. As the first option in Section 4, - well-known anycast addresses can be used as a last resort when - RDNSS information can not be obtained through either RA option or - DHCP option. This case needs IPv6 hosts to preconfigure the well- - known anycast addresses in their DNS configuration files. - - When the enterprise prefers well-known anycast approach to the - others, IPv6 hosts should preconfigure the well-known anycast - addresses like in the first option. - - The last option, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - because the addresses are delivered to IPv6 hosts through either RA - option or DHCPv6 option as if they were unicast addresses. This - way is most recommended for the sake of user's convenience. - -5.3 3GPP Network - - IPv6 DNS configuration is a missing part of IPv6 autoconfiguration - and an important part of the basic IPv6 functionality in the 3GPP - User Equipment (UE). Higher level description of the 3GPP - architecture can be found in [18], and transition to IPv6 in 3GPP - networks is analyzed in [19] and [20]. - - - -Jeong, et al. Expires - January 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - In 3GPP architecture, there is a dedicated link between the UE and - the GGSN called the Packet Data Protocol (PDP) Context. This link - is created through the PDP Context activation procedure [21]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If - a 3GPP UE user is communicating using IPv6 (having an active IPv6 - PDP context), it can not be assumed that (s)he has simultaneously - active IPv4 PDP context, and DNS queries could be done using IPv4. - A 3GPP UE can thus be an IPv6 node, and it needs to somehow - discover the address of the RDNSS. Before IP-based services (e.g., - web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS - addresses need to be discovered in the 3GPP UE. - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the Well-known addresses approach. - Section 5.3.5 finally summarizes the recommendations. - -5.3.1 Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism, in which RDNSS addresses can be - received in the PDP context activation (a control plane mechanism). - That is called the Protocol Configuration Options Information - Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be - received over the air (using text messages), or typed in manually - in the UE. Note that the two last mechanisms are not very well - scalable. The UE user most probably does not want to type IPv6 - RDNSS addresses manually in his/her UE. The use of well-known - addresses is briefly discussed in section 5.3.4. - - It is seen that the mechanisms above most probably are not - sufficient for the 3GPP environment. IPv6 is intended to operate - in a zero-configuration manner, no matter what the underlying - network infrastructure is. Typically, the RDNSS address is needed - to make an IPv6 node operational - and the DNS configuration should - be as simple as the address autoconfiguration mechanism. It must - also be noted that there will be additional IP interfaces in some - near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific - DNS configuration mechanisms (such as PCO-IE [22]) do not work for - those IP interfaces. In other words, a good IPv6 DNS configuration - mechanism should also work in a multi-access network environment. - - From 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (can be - even hundreds of millions in one operator's network), is automatic - and thus requires no user action. It is suggested to standardize a - lightweight, stateless mechanism that works in all network - environments. The solution could then be used for 3GPP, 3GPP2, - - -Jeong, et al. Expires - January 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - WLAN and other access network technologies. A light, stateless - IPv6 DNS configuration mechanism is thus not only needed in 3GPP - networks, but also 3GPP networks and UEs would certainly benefit - from the new mechanism. - -5.3.2 RA Extension - - Router Advertisement extension [8] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in 3GPP UE IPv6 - stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified - in the IETF (no action needed in the 3GPP) and taken in use in 3GPP - UEs and GGSNs. - - In this solution, an IPv6-capable UE configures DNS information - via RA message sent by its default router (GGSN), i.e., RDNSS - option for recursive DNS server is included in the RA message. - This solution is easily scalable for a very large number of UEs. - The operator can configure the RDNSS addresses in the GGSN as a - part of normal GGSN configuration. The IPv6 RDNSS address is - received in the Router Advertisement, and an extra Round Trip Time - (RTT) for asking RDNSS addresses can be avoided. - - If thinking about cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - -5.3.3 Stateless DHCPv6 - - DHCPv6-based solution needs the implementation of Stateless DHCP - [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in - the operator's network. A possible configuration is such that the - GGSN works as a DHCP relay. - - Pros for Stateless DHCPv6-based solution are - 1) Stateless DHCPv6 is a standardized mechanism. - - 2) DHCPv6 can be used for receiving other configuration information - than RDNSS addresses, e.g., SIP server addresses. - - 3) DHCPv6 works in different network environments. - - 4) When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - - -Jeong, et al. Expires - January 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - Some issues with DHCPv6 in 3GPP networks are listed below: - 1) DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into an existing - router already, and it is one box more to be maintained. - - 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used), and - not automatically implemented in 3GPP IPv6 UEs. - - 3) Scalability and reliability of DHCPv6 in very large 3GPP - networks (with tens or hundreds of millions of UEs) may be an issue, - at least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as - router operating system, scalability and reliability is comparable - with other DNS configuration approaches. - - 4) It is sub-optimal to utilize the radio resources in 3GPP - networks for DHCPv6 messages if there is a simpler alternative - available. - - a) Use of Stateless DHCPv6 adds one round trip delay to the case - in which the UE can start transmitting data right after the - Router Advertisement. - - 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can - not automatically update the UE, see [23]. - -5.3.4 Well-known Addresses - - Using well-known addresses is also a feasible and a light mechanism - for 3GPP UEs. Those well-known addresses can be preconfigured in - the UE software and the operator makes the corresponding - configuration on the network side. So this is a very easy - mechanism for the UE, but requires some configuration work in the - network. When using well-known addresses, UE forwards queries to - any of the preconfigured addresses. In the current proposal [9], - IPv6 anycast addresses are suggested. - - Note: IPv6 DNS configuration proposal based on the use of well- - known site-local addresses developed at the IPv6 Working Group was - seen as a feasible mechanism for 3GPP UEs, but opposition by some - people in the IETF and finally deprecating IPv6 site-local - addresses made it impossible to standardize it. Note that this - mechanism is implemented in some existing operating systems today - (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration. - -5.3.5 Recommendations - - - -Jeong, et al. Expires - January 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - It is suggested that a lightweight, stateless DNS configuration - mechanism is specified as soon as possible. From 3GPP UE's and - networks' point of view, Router Advertisement based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can get rid of using well-known site-local - addresses for IPv6 DNS configuration. - -5.4 Unmanaged Network - - There are 4 deployment scenarios of interest in unmanaged networks - [24]: - - 1) A gateway which does not provide IPv6 at all; - - 2) A dual-stack gateway connected to a dual-stack ISP; - - 3) A dual-stack gateway connected to an IPv4-only ISP; and - - 4) A gateway connected to an IPv6-only ISP. - -5.4.1 Case A: Gateway does not provide IPv6 at all - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - The case where dual-stack hosts behind an NAT, that need access to - an IPv6 RDNSS, can not be entirely ruled out. The DNS - configuration mechanism has to work over the tunnel, and the - underlying tunneling mechanism could be implementing NAT traversal. - The tunnel server assumes the role of a relay (both for DHCP and - Well-known anycast addresses approaches). - - RA-based mechanism is relatively straightforward in its operation, - assuming the tunnel server is also the IPv6 router emitting RAs. - Well-known anycast addresses approach seems also simple in - operation across the tunnel, but the deployment model using Well- - known anycast addresses in a tunneled environment is unclear or not - well understood. - -5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. Except that - Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the - DHCP server is stateful (maintains the state for clients). - - - - -Jeong, et al. Expires - January 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - -5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity - by managing tunnels, then it is also supposed to provide access to - an RDNSS. Like this, the tunnel for IPv6 connectivity originates - from the dual-stack gateway instead of the host. - -5.4.4 Case D: A gateway connected to an IPv6-only ISP - - This is similar to Case B. - -6. Security Considerations - - As security requirements depend solely on applications and are - different application by application, there can be no generic - requirement defined at higher IP or lower application layer of DNS. - - However, it should be noted that cryptographic security requires - configured secret information that full autoconfiguration and - cryptographic security are mutually exclusive. People insisting on - secure full autoconfiguration will get false security, false - autoconfiguration or both. - - In some deployment scenario [19], where cryptographic security is - required for applications, secret information for the cryptographic - security is preconfigured through which application specific - configuration data, including those for DNS, can be securely - configured. It should be noted that if applications requiring - cryptographic security depend on DNS, the applications also require - cryptographic security to DNS. Therefore, the full auto- - configuration of DNS is not acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be - acceptable. That is, with full autoconfiguration, which means - there is no cryptographic security for the autoconfiguration, it is - already assumed that local environment is secure enough that - information from local autoconfiguration server has acceptable - security even without cryptographic security. Thus, communication - between a local DNS client and a local DNS server has the - acceptable security. - - For security considerations of each approach, refer to the - corresponding drafts [5]-[9]. - -7. Acknowledgements - - - - -Jeong, et al. Expires - January 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - This draft has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, and Thomas Narten. The authors appreciate their - contribution. - -8. Normative References - - [1] S. Bradner, "Intellectual Property Rights in IETF Technology", - RFC 3668, February 2004. - - [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February - 2004. - - [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for - IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] S. Thomson and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [6] R. Droms, "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - [7] R. Droms et al., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December - 2003. - -9. Informative References - - [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS - Discovery based on Router Advertisement", draft-jeong-dnsop- - ipv6-dns-discovery-02.txt, July 2004. - - [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta- - preconfigured-dns-01.txt, February 2004. - - [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft- - ietf-dhc-lifetime-00.txt, March 2004. - - [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - - - -Jeong, et al. Expires - January 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 - into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis- - 02.txt, April 2004. - - [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft- - ietf-send-ndopt-05.txt, April 2004. - - [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft- - ietf-v6ops-ent-scenarios-01.txt, February 2004. - - [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, December - 2003. - - [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP - Standards", RFC 3314, September 2002. - - [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", - RFC 3574, August 2003. - - [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004. - - [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless- - dhcpv6-renumbering-00.txt, March 2004. - - [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition - Scenarios", RFC 3750, April 2004. - -10. Authors' Addresses - - Jaehoon Paul Jeong, Editor - ETRI / PEC - 161 Gajeong-dong, Yuseong-gu - Daejeon 305-350 - Korea - - - -Jeong, et al. Expires - January 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - Phone: +82 42 860 1664 - Fax: +82 42 861 5404 - EMail: paul@etri.re.kr - - Ralph Droms - Cisco Systems - 1414 Massachusetts Ave. - Boxboro, MA 01719 - USA - - Phone: +1 978 936 1674 - EMail: rdroms@cisco.com - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - USA - - Phone: +1 650 625 2004 - EMail: bob.hinden@nokia.com - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - USA - - EMail: Ted.Lemon@nominum.com - - Masataka Ohta - Graduate School of Information Science and Engineering - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - EMail: mohta@necom830.hpcl.titech.ac.jp - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416, Maetan-3dong, Paldal-gu, Suwon - Gyeonggi-Do - Korea - - Phone: +82 31 200 4508 - - -Jeong, et al. Expires - January 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - EMail: soohong.park@samsung.com - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - USA - - EMail: satapati@cisco.com - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720 TAMPERE - Finland - - Phone: +358 7180 48372 - EMail: juha.wiljakka@nokia.com - -Intellectual Property Statement - - The following intellectual property notice is copied from RFC3668, - Section 5. - - 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. - -Full Copyright Statement - - - - -Jeong, et al. Expires - January 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The following copyright notice is copied from RFC3667, Section 5.4. - It describes the applicable copyright for this document. - - Copyright (C) The Internet Society (2004). This document is - subject to the rights, licenses and restrictions contained in BCP - 78, and except as set forth therein, the authors retain all their - rights. - - This document and the information contained herein are provided on - an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT - THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR - ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A - PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong, et al. Expires - January 2005 [Page 24] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt deleted file mode 100644 index b14f711..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt +++ /dev/null @@ -1,1969 +0,0 @@ - - -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: February 7, 2005 J. Ihren - Autonomica - P. Savola - CSC/FUNET - August 9, 2004 - - - - Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-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 February 7, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, - recommendations and considerations on how to perform DNS naming for - - - - -Durand, et al. Expires February 7, 2005 [Page 1] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - service provisioning and for DNS resolver IPv6 support, - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - - -Table of Contents - - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 8 - 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 - 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 - 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 - 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 - 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 - - - - -Durand, et al. Expires February 7, 2005 [Page 2] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 - B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . 30 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 3] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -1. Introduction - - - This memo presents operational considerations and issues with IPv6 - DNS; it is meant to be an extensive summary and a list of pointers - for more information about IPv6 DNS considerations for those with - experience with IPv4 DNS. - - - The purpose of this document is to give information about various - issues and considerations related to DNS operations with IPv6; it is - not meant to be a normative specification or standard for IPv6 DNS. - - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for site-local addressing. - - -1.1 Representing IPv6 Addresses in DNS Records - - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. tree. See - [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] - for background information. - - - In particular one should note that the use of A6 records in the - forward tree or Bitlabels in the reverse tree is not recommended - [RFC3363]. Using DNAME records is not recommended in the reverse - tree in conjunction with A6 records; the document did not mean to - take a stance on any other use of DNAME records [RFC3364]. - - -1.2 Independence of DNS Transport and DNS Records - - - DNS has been designed to present a single, globally unique name space - [RFC2826]. This property should be maintained, as described here and - - - - -Durand, et al. Expires February 7, 2005 [Page 4] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - in Section 1.3. - - - The IP version used to transport the DNS queries and responses is - independent of the records being queried: AAAA records can be queried - over IPv4, and A records over IPv6. The DNS servers must not make - any assumptions about what data to return for Answer and Authority - sections based on the underlying transport used in a query. - - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - transport was being used; this has some obvious problems because in - many cases the transport protocol does not correlate with the - requests, and because a "bad" answer is in a way worse than no answer - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - at all). - - - As stated in [RFC3596]: - - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation - - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines - [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. - - -1.4 Query Type '*' and A/AAAA Records - - - QTYPE=* is typically only used for debugging or management purposes; - it is worth keeping in mind that QTYPE=* ("ANY" queries) only return - any available RRsets, not *all* the RRsets, because the caches do not - necessarily have all the RRsets and have no way of guaranteeing that - they have all the RRsets. Therefore, to get both A and AAAA records - reliably, two separate queries must be made. - - -2. DNS Considerations about Special IPv6 Addresses - - - There are a couple of IPv6 address types which are somewhat special; - these are considered here. - - - - - - -Durand, et al. Expires February 7, 2005 [Page 5] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -2.1 Limited-scope Addresses - - - The IPv6 addressing architecture [RFC3513] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local (fec0::/ - 10). The site-local addresses have been deprecated - [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in - Appendix A. - - - Link-local addresses should never be published in DNS (whether in - forward or reverse tree), because they have only local (to the - connected link) significance - [I-D.ietf-dnsop-dontpublish-unreachable]. - - -2.2 Temporary Addresses - - - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called - "privacy addresses") use a random number as the interface identifier. - Publishing (useful) DNS records relating to such addresses would - defeat the purpose of the mechanism and is not recommended. However, - it would still be possible to return a non-identifiable name (e.g., - the IPv6 address in hexadecimal format), as described in [RFC3041]. - - -2.3 6to4 Addresses - - - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. - - - If the reverse DNS population would be desirable (see Section 7.1 for - applicability), there are a number of possible ways to do so - [I-D.moore-6to4-dns], some more applicable than the others. - - - The main proposal [I-D.huston-6to4-reverse-dns] aims to design an - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. - - -2.4 Other Transition Mechanisms - - - 6to4, above, is mentioned as a case of an IPv6 transition mechanism - requiring special considerations. In general, mechanisms which - include a special prefix may need a custom solution; otherwise, for - example when IPv4 address is embedded as the suffix or not embedded - at all, special solutions are likely not needed. This is why only - 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. - - - Note that it does not seem feasible to provide reverse DNS with - - - - -Durand, et al. Expires February 7, 2005 [Page 6] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - another automatic tunneling mechanism, Teredo; this is because the - IPv6 address is based on the IPv4 address and UDP port of the current - NAT mapping which is likely to be relatively short-lived. - - -3. Observed DNS Implementation Misbehaviour - - - Several classes of misbehaviour in DNS servers, load-balancers and - resolvers have been observed. Most of these are rather generic, not - only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and - deserve to be mentioned. - - -3.1 Misbehaviour of DNS Servers and Load-balancers - - - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented - [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations - silently drop queries for unimplemented DNS records types, or provide - wrong answers to such queries (instead of a proper negative reply). - While typically these issues are not limited to AAAA records, the - problems are aggravated by the fact that AAAA records are being - queried instead of (mainly) A records. - - - The problems are serious because when looking up a DNS name, typical - getaddrinfo() implementations, with AF_UNSPEC hint given, first try - to query the AAAA records of the name, and after receiving a - response, query the A records. This is done in a serial fashion -- - if the first query is never responded to (instead of properly - returning a negative answer), significant timeouts will occur. - - - In consequence, this is an enormous problem for IPv6 deployments, and - in some cases, IPv6 support in the software has even been disabled - due to these problems. - - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the timeout as long as at - least one answer has been received; but such methods remain to be - investigated; slightly more on this is included in Section 5. - - -3.2 Misbehaviour of DNS Resolvers - - - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. - - - - - -Durand, et al. Expires February 7, 2005 [Page 7] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -4. Recommendations for Service Provisioning using DNS - - - When names are added in the DNS to facilitate a service, there are - several general guidelines to consider to be able to do it as - smoothly as possible. - - -4.1 Use of Service Names instead of Node Names - - - When a node provides multiple services which should not be - fate-sharing, or might support different IP versions, one should keep - them logically separate in the DNS. Using SRV records [RFC2782] - would avoid these problems. Unfortunately, those are not - sufficiently widely used to be applicable in most cases. Hence an - operation technique is to use service names instead of node names - (or, "hostnames"). This operational technique is not specific to - IPv6, but required to understand the considerations described in - Section 4.2 and Section 4.3. - - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one should use - e.g., "smtp.example.com" for SMTP (for both message submission and - mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of SMTP relaying, the server itself - must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) - - - This is a good practice with IPv4 as well, because it provides more - flexibility and enables easier migration of services from one host to - another. A specific reason why this is relevant for IPv6 is that the - different services may have a different level of IPv6 support -- that - is, one node providing multiple services might want to enable just - one service to be IPv6-visible while keeping some others as - IPv4-only, improving flexibility. - - -4.2 Separate vs the Same Service Names for IPv4 and IPv6 - - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could be either added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, - "service.ipv6.example.com". - - - These two methods have different characteristics. Using a different - - - - -Durand, et al. Expires February 7, 2005 [Page 8] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - name allows for easier service piloting, minimizing the disturbance - to the "regular" users of IPv4 service; however, the service would - not be used transparently, without the user/application explicitly - finding it and asking for it -- which would be a disadvantage in most - cases. When the different name is under a sub-domain, if the - services are deployed within a restricted network (e.g., inside an - enterprise), it's possible to prefer them transparently, at least to - a degree, by modifying the DNS search path; however, this is a - suboptimal solution. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see Section - 4.3 for more). - - - In most cases, it makes sense to pilot or test a service using - separate service names, and move to the use of the same name when - confident enough that the service level will not degrade for the - users unaware of IPv6. - - -4.3 Adding the Records Only when Fully IPv6-enabled - - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - - 1. The address is assigned to the interface on the node. - - - 2. The address is configured on the interface. - - - 3. The interface is on a link which is connected to the IPv6 - infrastructure. - - - In addition, if the AAAA record is added for the node, instead of - service as recommended, all the services of the node should be - IPv6-enabled prior to adding the resource record. - - - For example, if an IPv6 node is isolated from an IPv6 perspective - (e.g., it is not connected to IPv6 Internet) constraint #3 would mean - that it should not have an address in the DNS. - - - Consider the case of two dual-stack nodes, which both have IPv6 - enabled, but the server does not have (global) IPv6 connectivity. As - the client looks up the server's name, only A records are returned - (if the recommendations above are followed), and no IPv6 - communication, which would have been unsuccessful, is even attempted. - - - The issues are not always so black-and-white. Usually it's important - if the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - latency, throughput, low packet loss, general reliability, etc.) -- - - - - -Durand, et al. Expires February 7, 2005 [Page 9] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - this is typically very important especially for interactive or - real-time services. In many cases, the quality of IPv6 connectivity - may not yet be equal to that of IPv4, at least globally -- this has - to be taken into consideration when enabling services - [I-D.savola-v6ops-6bone-mess]. - - -4.4 Behaviour of Additional Data in IPv4/IPv6 Environments - - -4.4.1 Description of Additional Data Scenarios - - - Consider the case where the query name is so long, the number of the - additional records is so high, or for other reasons that the entire - response would not fit in a single UDP packet. In some cases, the - responder truncates the response with the TC bit being set (leading - to a retry with TCP), in order for the querier to get the entire - response later. - - - There are two kinds of additional data: - - - 1. glue, i.e., "critical" additional data; this must be included in - all scenarios, with all the RRsets as possible, and - - - 2. "courtesy" additional data; this could be sent in full, with only - a few RRsets, or with no RRsets, and can be fetched separately as - well, but at the cost of additional queries. This data must - never cause setting of the TC bit. - - - The responding server can algorithmically determine which type the - additional data is by checking whether it's at or below a zone cut. - - - Meanwhile, resource record sets (RRsets) are never "broken up", so if - a name has 4 A records and 5 AAAA records, you can either return all - 9, all 4 A records, all 5 AAAA records or nothing. In particular, - notice that for the "critical" additional data getting all the RRsets - can be critical. - - - An example of the "courtesy" additional data is A/AAAA records in - conjunction of MX records as shown in Section 4.5; an example of the - "critical" additional data is shown below (where getting both the A - and AAAA RRsets is critical): - - - child.example.com. IN NS ns.child.example.com. - ns.child.example.com. IN A 192.0.2.1 - ns.child.example.com. IN AAAA 2001:db8::1 - - - When there is too much courtesy additional data, some or all of it - need to be removed [RFC2181]; if some is left in the response, the - issue is which data should be retained. When there is too much - - - - -Durand, et al. Expires February 7, 2005 [Page 10] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - critical additional data, TC bit will have to be set, and some or all - of it need to be removed; if some is left in the response, the issue - is which data should be retained. - - - If the implementation decides to keep as much data as possible, it - might be tempting to use the transport of the DNS query as a hint in - either of these cases: return the AAAA records if the query was done - over IPv6, or return the A records if the query was done over IPv4. - However, this breaks the model of independence of DNS transport and - resource records, as noted in Section 1.2. - - - It is worth remembering that often the host using the records is - different from the node requesting them from the authoritative DNS - server (or even a caching resolver). So, whichever version the - requestor (e.g., a recursive server in the middle) uses makes no - difference to the ultimate user of the records, whose transport - capabilities might differ from those of the requestor. This might - result in e.g., inappropriately returning A records to an IPv6-only - node, going through a translation, or opening up another IP-level - session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). - Therefore, at least in many scenarios, it would be very useful if the - information returned would be consistent and complete -- or if that - is not feasible, return no misleading information but rather leave it - to the client to query again. - - -4.4.2 Discussion of the Problems - - - As noted above, the temptation for omitting only some of the - additional data based on the transport of the query could be - problematic. In particular, there appears to be little justification - for doing so in the case of "courtesy" data. - - - However, with critical additional data, the alternatives are either - returning nothing (and requiring a retry with TCP) or returning - something (possibly obviating the need for a retry with TCP). If the - process for selecting "something" from the critical data would - otherwise be practically "flipping the coin" between A and AAAA - records, it could be argued that if one looked at the transport of - the query, it would have a larger possibility of being right than - just 50/50. In other words, if the returned critical additional data - would have to be selected somehow, using something more sophisticated - than a random process would seem justifiable. - - - The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - returned either truncated or missing some RRsets to the users. A - protocol fix for this is using EDNS0 [RFC2671] to signal the capacity - for larger UDP packet sizes, pushing up the relevant threshold. - - - - -Durand, et al. Expires February 7, 2005 [Page 11] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Further, DNS server implementations should rather omit courtesy - additional data completely rather than including only some RRsets - [RFC2181]. An operational fix for this is having the DNS server - implementations return a warning when the administrators create zones - which would result in too much additional data being returned. - Further, DNS server implementations should warn of or disallow such - zone configurations which are recursive or otherwise difficult to - manage by the protocol. - - - Additionally, to avoid the case where an application would not get an - address at all due to some of "courtesy" additional data being - omitted, the resolvers should be able to query the specific records - of the desired protocol, not just rely on getting all the required - RRsets in the additional section. - - -4.5 The Use of TTL for IPv4 and IPv6 RRs - - - In the previous section, we discussed a danger with queries, - potentially leading to omitting RRsets from the additional section; - this could happen to both critical and "courtesy" additional data. - This section discusses another problem with the latter, leading to - omitting RRsets in cached data, highlighted in the IPv4/IPv6 - environment. - - - The behaviour of DNS caching when different TTL values are used for - different RRsets of the same name requires explicit discussion. For - example, let's consider a part of a zone: - - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - - When a caching resolver asks for the MX record of example.com, it - gets back "foo.example.com". It may also get back either one or both - of the A and AAAA records in the additional section. So, there are - three cases about returning records for the MX in the additional - section: - - - 1. We get back no A or AAAA RRsets: this is the simplest case, - because then we have to query which information is required - explicitly, guaranteeing that we get all the information we're - interested in. - - - 2. We get back all the RRsets: this is an optimization as there is - no need to perform more queries, causing lower latency. However, - it is impossible to guarantee that in fact we would always get - back all the records (the only way to ensure that is to send a - AAAA query for the name after getting the cached reply with A - - - - -Durand, et al. Expires February 7, 2005 [Page 12] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - records or vice versa). - - - 3. We only get back A or AAAA RRsets even if both existed: this is - indistinguishable from the previous case, and may have problems - at least in certain environments as described in the previous - section. - - - As the third case was considered in the previous section, we assume - we get back both A and AAAA records of foo.example.com, or the stub - resolver explicitly asks, in two separate queries, both A and AAAA - records. - - - After 100 seconds, the AAAA record is removed from the cache(s) - because its TTL expired. It could be argued to be useful for the - caching resolvers to discard the A record when the shorter TTL (in - this case, for the AAAA record) expires; this would avoid the - situation where there would be a window of 200 seconds when - incomplete information is returned from the cache. The behaviour in - this scenario is unspecified. - - - To simplify the situation, it might help to use the same TTL for all - the resource record sets referring to the same name, unless there is - a particular reason for not doing so. However, there are some - scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where - a different strategy is preferable. - - - Thus, applications that use the response should not rely on a - particular TTL configuration. For example, even if an application - gets a response that only has the A record in the example described - above, it should be still aware that there could be a AAAA record for - "foo.example.com". That is, the application should try to fetch the - missing records itself if it needs the record. - - -4.6 IPv6 Transport Guidelines for DNS Servers - - - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to - be at least one authoritative IPv4 DNS server for every zone, even if - the zone has only IPv6 records. (Note that obviously, having more - servers with robust connectivity would be preferable, but this is the - minimum recommendation; also see [RFC2182].) - - -5. Recommendations for DNS Resolver IPv6 Support - - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - - - - - - -Durand, et al. Expires February 7, 2005 [Page 13] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -5.1 DNS Lookups May Query IPv6 Records Prematurely - - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: - - - 1. The system library does not know whether IPv6 has been enabled in - the kernel of the operating system: it may start looking up AAAA - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. - - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. - - - First, let us consider generic implications of unnecessary queries - for AAAA records: when looking up all the records in the DNS, AAAA - records are typically tried first, and then A records. These are - done in serial, and the A query is not performed until a response is - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up - delay for AAAA may incur additional unnecessary latency, and - introduce a component of unreliability. - - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). - - - An additional concern is the address selection, which may, in some - circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. - - - Now, we can consider the issues specific to each of the three - - - - -Durand, et al. Expires February 7, 2005 [Page 14] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - possibilities: - - - In the first case, the node performs a number of completely useless - DNS lookups as it will not be able to use the returned AAAA records - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - should be able to disable these unnecessary queries, for both latency - and reliability reasons. However, as IPv6 has not been enabled, the - connections to IPv6 addresses fail immediately, and if the - application is programmed properly, the application can fall - gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. - - - The second case is similar to the first, except it happens to a - smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. - - - The third case is a bit more complex: optimizing away the DNS lookups - with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That is, - performing DNS lookups only when a non-link-local address has been - configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. - - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - - -5.2 Obtaining a List of DNS Recursive Resolvers - - - In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. - - - The IETF is considering the development of alternative mechanisms for - obtaining the list of DNS recursive name servers when DHCPv6 is - unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. - - - In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - - - - -Durand, et al. Expires February 7, 2005 [Page 15] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information - [I-D.jeong-dnsop-ipv6-dns-discovery]. - - - Note that even though IPv6 DNS resolver discovery is a recommended - procedure, it is not required for dual-stack nodes in dual-stack - networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual - configuration in IPv6-only networks must implement the DNS resolver - discovery function. - - -5.3 IPv6 Transport Guidelines for Resolvers - - - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers - should be IPv4-only or dual-stack to be able to reach any IPv4-only - DNS server. Note that this requirement is also fulfilled by an - IPv6-only stub resolver pointing to a dual-stack recursive DNS - resolver. - - -6. Considerations about Forward DNS Updating - - - While the topic how to enable updating the forward DNS, i.e., the - mapping from names to the correct new addresses, is not specific to - IPv6, it should be considered especially due to the advent of - Stateless Address Autoconfiguration [RFC2462]. - - - Typically forward DNS updates are more manageable than doing them in - the reverse DNS, because the updater can often be assumed to "own" a - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node which is allowed to update it to point - to a new address. - - - A more complex form of DNS updates -- adding a whole new name into a - DNS zone, instead of updating an existing name -- is considered out - of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still - being explored with IPv4, and IPv6 does not seem to add much new in - that area. - - -6.1 Manual or Custom DNS Updates - - - The DNS mappings can also be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - considered at more length in this memo. - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 16] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -6.2 Dynamic DNS - - - Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized - mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual - address configuration. It is important to consider how each of these - behave if IP address-based authentication, instead of stronger - mechanisms [RFC3007], was used in the updates. - - - 1. manual addresses are static and can be configured - - - 2. DHCPv6 addresses could be reasonably static or dynamic, depending - on the deployment, and could or could not be configured on the - DNS server for the long term - - - 3. SLAAC addresses are typically stable for a long time, but could - require work to be configured and maintained. - - - As relying on IP addresses for Dynamic DNS is rather insecure at - best, stronger authentication should always be used; however, this - requires that the authorization keying will be explicitly configured - using unspecified operational methods. - - - Note that with DHCP it is also possible that the DHCP server updates - the DNS, not the host. The host might only indicate in the DHCP - exchange which hostname it would prefer, and the DHCP server would - make the appropriate updates. Nonetheless, while this makes setting - up a secure channel between the updater and the DNS server easier, it - does not help much with "content" security, i.e., whether the - hostname was acceptable -- if the DNS server does not include - policies, they must be included in the DHCP server (e.g., a regular - host should not be able to state that its name is "www.example.com"). - DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. - - - The nodes must somehow be configured with the information about the - servers where they will attempt to update their addresses, sufficient - security material for authenticating themselves to the server, and - the hostname they will be updating. Unless otherwise configured, the - first could be obtained by looking up the authoritative name servers - for the hostname; the second must be configured explicitly unless one - chooses to trust the IP address-based authentication (not a good - idea); and lastly, the nodename is typically pre-configured somehow - on the node, e.g., at install time. - - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the addresses, so - - - - -Durand, et al. Expires February 7, 2005 [Page 17] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - that if the node is renumbered in a managed fashion, the amount of - stale DNS information is kept to the minimum. That is, if the - preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For - better flexibility, the DNS TTL should be much shorter (e.g., a half - or a third) than the lifetime of an address; that way, the node can - start lowering the DNS TTL if it seems like the address has not been - renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in - [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to - (smart) hosts as well. - - -7. Considerations about Reverse DNS Updating - - - Updating the reverse DNS zone may be difficult because of the split - authority over an address. However, first we have to consider the - applicability of reverse DNS in the first place. - - -7.1 Applicability of Reverse DNS - - - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a - reverse record for an address would signal some form of - authorization). - - - One additional, maybe slightly more useful usage is ensuring that the - reverse and forward DNS contents match (by looking up the pointer to - the name by the IP address from the reverse tree, and ensuring that a - record under the name in the forward tree points to the IP address) - and correspond to a configured name or domain. As a security check, - it is typically accompanied by other mechanisms, such as a user/ - password login; the main purpose of the reverse+forward DNS check is - to weed out the majority of unauthorized users, and if someone - managed to bypass the checks, he would still need to authenticate - "properly". - - - It may also be desirable to store IPsec keying material corresponding - to an IP address to the reverse DNS, as justified and described in - [I-D.ietf-ipseckey-rr]. - - - It is not clear whether it makes sense to require or recommend that - reverse DNS records be updated. In many cases, it would just make - more sense to use proper mechanisms for security (or topological - information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record - - - - -Durand, et al. Expires February 7, 2005 [Page 18] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - - The applicability is discussed at more length in - [I-D.ietf-dnsop-inaddr-required]. - - -7.2 Manual or Custom DNS Updates - - - Reverse DNS can of course be updated using manual or custom methods. - These are not further described here, except for one special case. - - - One way to deploy reverse DNS would be to use wildcard records, for - example, by configuring one name for a subnet (/64) or a site (/48). - As a concrete example, a site (or the site's ISP) could configure the - reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, but would at least provide some form of "topological - information" or "weak authorization" if that is really considered to - be useful. Note that this is not actually updating the DNS as such, - as the whole point is to avoid DNS updates completely by manually - configuring a generic name. - - -7.3 DDNS with Stateless Address Autoconfiguration - - - Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in - some regard, while being more difficult in another, as described - below. - - - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are, a simple - address-based authorization is typically sufficient (i.e., check that - the DNS update is done from the same IP address as the record being - updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. (Such - address-based update authorization operationally requires that - ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible.) - - - Address-based authorization is simpler with reverse DNS (as there is - a connection between the record and the address) than with forward - DNS. However, when a stronger form of security is used, forward DNS - updates are simpler to manage because the host can be assumed to have - an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - with the owner of that address space -- so, assuming stronger form of - authorization for reverse DNS updates than an address association is - generally unfeasible. - - - - -Durand, et al. Expires February 7, 2005 [Page 19] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Moreover, the reverse zones must be cleaned up by an unspecified - janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. - - - A problem with defining the clean-up process is that it is difficult - to ensure that a specific IP address and the corresponding record are - no longer being used. Considering the huge address space, and the - unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic - has been seen from a node in a long period of time (e.g., a month or - year) might be one possible approach. - - - To insert or update the record, the node must discover the DNS server - to send the update to somehow, similar to as discussed in Section - 6.2. One way to automate this is looking up the DNS server - authoritative (e.g., through SOA record) for the IP address being - updated, but the security material (unless the IP address-based - authorization is trusted) must also be established by some other - means. - - - One should note that Cryptographically Generated Addresses - [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of - treatment. CGAs are addresses where the interface identifier is - calculated from a public key, a modifier (used as a nonce), the - subnet prefix, and other data. Depending on the usage profile, CGAs - might or might not be changed periodically due to e.g., privacy - reasons. As the CGA address is not predicatable, a reverse record - can only reasonably be inserted in the DNS by the node which - generates the address. - - -7.4 DDNS with DHCP - - - With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One - can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no - updating. - - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one (if an address - assignment policy that reassigns disused addresses is adopted) and - updating a record seems like a slightly more difficult thing to - secure. However, it is yet uncertain how DHCPv6 is going to be used - for address assignment. - - - Note that when using DHCP, either the host or the DHCP server could - - - - -Durand, et al. Expires February 7, 2005 [Page 20] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - perform the DNS updates; see the implications in Section 6.2. - - - If disused addresses were to be reassigned, host-based DDNS reverse - updates would need policy considerations for DNS record modification, - as noted above. On the other hand, if disused address were not to be - assigned, host-based DNS reverse updates would have similar - considerations as SLAAC in Section 7.3. Server-based updates have - similar properties except that the janitorial process could be - integrated with DHCP address assignment. - - -7.5 DDNS with Dynamic Prefix Delegation - - - In cases where a prefix, instead of an address, is being used and - updated, one should consider what is the location of the server where - DDNS updates are made. That is, where the DNS server is located: - - - 1. At the same organization as the prefix delegator. - - - 2. At the site where the prefixes are delegated to. In this case, - the authority of the DNS reverse zone corresponding to the - delegated prefix is also delegated to the site. - - - 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. - - - In the first case, managing the reverse DNS (delegation) is simpler - as the DNS server and the prefix delegator are in the same - administrative domain (as there is no need to delegate anything at - all); alternatively, the prefix delegator might forgo DDNS reverse - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more - difficult, particularly as the site will have to configure the DNS - server to be authoritative for the delegated reverse zone, implying - automatic configuration of the DNS server -- as the prefix may be - dynamic. - - - Managing the DDNS reverse updates is typically simple in the second - case, as the updated server is located at the local site, and - arguably IP address-based authentication could be sufficient (or if - not, setting up security relationships would be simpler). As there - is an explicit (security) relationship between the parties in the - third case, setting up the security relationships to allow reverse - DDNS updates should be rather straightforward as well (but IP - address-based authentication might not be acceptable). In the first - case, however, setting up and managing such relationships might be a - lot more difficult. - - - - -Durand, et al. Expires February 7, 2005 [Page 21] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -8. Miscellaneous DNS Considerations - - - This section describes miscellaneous considerations about DNS which - seem related to IPv6, for which no better place has been found in - this document. - - -8.1 NAT-PT with DNS-ALG - - - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. - This is a strong reason not to use NAT-PT in the first place. - - -8.2 Renumbering Procedures and Applications' Use of DNS - - - One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that - an application which looks up a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. - - - While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and - libraries"), and a lot more analysis is needed on how to practically - go about to achieve the ultimate goal of avoiding using the names - longer than expected. - - -9. Acknowledgements - - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik - Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided - useful feedback and improvements. Scott Rose, Rob Austein, Masataka - Ohta, and Mark Andrews helped in clarifying the issues regarding - additional data and the use of TTL. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - Narten provided extensive feedback during the IESG evaluation. - - -10. Security Considerations - - - This document reviews the operational procedures for IPv6 DNS - - - - -Durand, et al. Expires February 7, 2005 [Page 22] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - operations and does not have security considerations in itself. - - - However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are - very weak and cannot be recommended -- they could only be considered - in the environments where ingress filtering [RFC3704] has been - deployed. On the other hand, it should be noted that setting up an - authorization mechanism (e.g., a shared secret, or public-private - keys) between a node and the DNS server has to be done manually, and - may require quite a bit of time and expertise. - - - To re-emphasize which was already stated, the reverse+forward DNS - check provides very weak security at best, and the only - (questionable) security-related use for them may be in conjunction - with other mechanisms when authenticating a user. - - -11. References - - -11.1 Normative References - - - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-ipv6-transport-guidelines] - Durand, A. and J. Ihren, "DNS IPv6 transport operational - guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 - (work in progress), March 2004. - - - [I-D.ietf-dnsop-misbehavior-against-aaaa] - Morishita, Y. and T. Jinmei, "Common Misbehavior against - DNS Queries for IPv6 Addresses", - draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in - progress), April 2004. - - - [I-D.ietf-ipv6-deprecate-site-local] - Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work - in progress), March 2004. - - - [I-D.ietf-v6ops-application-transition] - Shin, M., "Application Aspects of IPv6 Transition", - draft-ietf-v6ops-application-transition-03 (work in - progress), June 2004. - - - [I-D.ietf-v6ops-renumbering-procedure] - - - - -Durand, et al. Expires February 7, 2005 [Page 23] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Baker, F., Lear, E. and R. Droms, "Procedures for - Renumbering an IPv6 Network without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-01 (work in - progress), July 2004. - - - [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. - - - [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and - M. Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - - [RFC3363] 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. - - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - - - - - -Durand, et al. Expires February 7, 2005 [Page 24] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October - 2003. - - - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - - - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - -11.2 Informative References - - - [I-D.durand-v6ops-natpt-dns-alg-issues] - Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", - draft-durand-v6ops-natpt-dns-alg-issues-00 (work in - progress), February 2003. - - - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-02 (work in progress), - June 2004. - - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS", - draft-huston-6to4-reverse-dns-02 (work in progress), April - 2004. - - - [I-D.ietf-dhc-ddns-resolution] - Stapp, M., "Resolution of DNS Name Conflicts Among DHCP - Clients", draft-ietf-dhc-ddns-resolution-07 (work in - progress), July 2004. - - - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-07 (work in progress), July - 2004. - - - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-08 (work in progress), July - 2004. - - - [I-D.ietf-dnsop-bad-dns-res] - - - - -Durand, et al. Expires February 7, 2005 [Page 25] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-dontpublish-unreachable] - Hazel, P., "IP Addresses that should never appear in the - public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 - (work in progress), February 2002. - - - [I-D.ietf-dnsop-inaddr-required] - Senie, D., "Requiring DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-05 (work in progress), - April 2004. - - - [I-D.ietf-ipseckey-rr] - Richardson, M., "A method for storing IPsec keying - material in DNS", draft-ietf-ipseckey-rr-11 (work in - progress), July 2004. - - - [I-D.ietf-ipv6-unique-local-addr] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in - progress), June 2004. - - - [I-D.ietf-send-cga] - Aura, T., "Cryptographically Generated Addresses (CGA)", - draft-ietf-send-cga-06 (work in progress), April 2004. - - - [I-D.ietf-v6ops-3gpp-analysis] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in - progress), May 2004. - - - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04 - (work in progress), July 2004. - - - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery - On-Link Assumption Considered Harmful", - draft-ietf-v6ops-onlinkassumption-02 (work in progress), - May 2004. - - - [I-D.ietf-v6ops-v6onbydefault] - Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - - - -Durand, et al. Expires February 7, 2005 [Page 26] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Discovery based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 - (work in progress), July 2004. - - - [I-D.moore-6to4-dns] - Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work - in progress), October 2002. - - - [I-D.ohta-preconfigured-dns] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - February 2004. - - - [I-D.savola-v6ops-6bone-mess] - Savola, P., "Moving from 6bone to IPv6 Internet", - draft-savola-v6ops-6bone-mess-01 (work in progress), - November 2002. - - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - - [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - - -Authors' Addresses - - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - - EMail: Alain.Durand@sun.com - - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 27] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - - EMail: johani@autonomica.se - - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - - EMail: psavola@funet.fi - - -Appendix A. Site-local Addressing Considerations for DNS - - - As site-local addressing has been deprecated, the considerations for - site-local addressing are discussed briefly here. Unique local - addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed - as a replacement, but being work-in-progress, it is not considered - further. - - - The interactions with DNS come in two flavors: forward and reverse - DNS. - - - To actually use site-local addresses within a site, this implies the - deployment of a "split-faced" or a fragmented DNS name space, for the - zones internal to the site, and the outsiders' view to it. The - procedures to achieve this are not elaborated here. The implication - is that site-local addresses must not be published in the public DNS. - - - To faciliate reverse DNS (if desired) with site-local addresses, the - stub resolvers must look for DNS information from the local DNS - servers, not e.g. starting from the root servers, so that the - site-local information may be provided locally. Note that the - experience of private addresses in IPv4 has shown that the root - servers get loaded for requests for private address lookups in any - case. - - -Appendix B. Issues about Additional Data or TTL - - - [[ note to the RFC-editor: remove this section upon publication. ]] - - - This appendix tries to describe the apparent rought consensus about - additional data and TTL issues (sections 4.4 and 4.5), and present - questions when there appears to be no consensus. The point of - - - - -Durand, et al. Expires February 7, 2005 [Page 28] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - recording them here is to focus the discussion and get feedback. - - - Resolved: - - - a. If some critical additional data RRsets wouldn't fit, you set the - TC bit even if some RRsets did fit. - - - b. If some courtesy additional data RRsets wouldn't fit, you never - set the TC bit, but rather remove (at least some of) the courtesy - RRsets. - - - c. DNS servers should implement sanity checks on the resulting glue, - e.g., to disable circular dependencies. Then the responding - servers can use at-or-below-a-zone-cut criterion to determine - whether the additional data is critical or not. - - - Open issues (at least): - - - 1. if some critical additional data RRsets would fit, but some - wouldn't, and TC has to be set (see above), should one rather - remove the additional data that did fit, keep it, or leave - unspecified? - - - 2. if some courtesy additional data RRsets would fit, but some - wouldn't, and some will have to be removed from the response (no - TC is set, see above), what to do -- remove all courtesy RRsets, - keep all that fit, or leave unspecified? - - - 3. is it acceptable to use the transport used in the DNS query as a - hint which records to keep if not removing all the RRsets, if: a) - having to decide which critical additional data to keep, or b) - having to decide which courtesy additional data to keep? - - - 4. (this issue was discussed in section 4.5) if one RRset has TTL of - 100 seconds, and another the TTL of 300 seconds, what should the - caching server do after 100 seconds? Keep returning just one - RRset when returning additional data, or discard the other RRset - from the cache? - - - 5. how do we move forward from here? If we manage to get to some - form of consensus, how do we record it: a) just in - draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational - category only!), b) a separate BCP or similar by DNSEXT WG(?), - clarifying and giving recommendations, c) something else, what? - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 29] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Durand, et al. Expires February 7, 2005 [Page 30]
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt deleted file mode 100644 index 2311ee6..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt +++ /dev/null @@ -1,391 +0,0 @@ - -DNSOP G. Guette -Internet-Draft IRISA / INRIA -Expires: February 5, 2005 O. Courtay - Thomson R&D - August 7, 2004 - - - Requirements for Automated Key Rollover in DNSSEC - draft-ietf-dnsop-key-rollover-requirements-01.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I 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 February 5, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document describes problems that appear during an automated - rollover and gives the requirements for the design of communication - between parent zone and child zone in an automated rollover process. - This document is essentially about key rollover, the rollover of - another Resource Record present at delegation point (NS RR) is also - discussed. - - - - - -Guette & Courtay Expires February 5, 2005 [Page 1] - -Internet-Draft Automated Rollover Requirements August 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Messages authentication and information exchanged . . . . . . 4 - 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Other Resource Record concerned by automatic rollover . . . . 5 - 7. Security consideration . . . . . . . . . . . . . . . . . . . . 5 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - Intellectual Property and Copyright Statements . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Guette & Courtay Expires February 5, 2005 [Page 2] - -Internet-Draft Automated Rollover Requirements August 2004 - - -1. Introduction - - The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key - cryptography and digital signatures. It stores the public part of - keys in DNSKEY Resource Records (RRs). Because old keys and - frequently used keys are vulnerable, they must be renewed - periodically. In DNSSEC, this is the case for Zone Signing Keys - (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key - rollover process is necessary for large zones because there are too - many changes to handle a manual administration. - - Let us consider for example a zone with 100000 secure delegations. - If the child zones change their keys once a year on average, that - implies 300 changes per day for the parent zone. This amount of - changes are hard to manage manually. - - Automated rollover is optional and resulting from an agreement - between the administrator of the parent zone and the administrator of - the child zone. Of course, key rollover can also be done manually by - administrators. - - This document describes the requirements for the design of messages - of automated key rollover process and focusses on interaction between - parent and child zone. - -2. The Key Rollover Process - - Key rollover consists in renewing the DNSSEC keys used to sign - resource records in a given DNS zone file. There are two types of - rollover, ZSK rollovers and KSK rollovers. - - In a ZSK rollover, all changes are local to the zone that renews its - key: there is no need to contact other zones (e.g., parent zone) to - propagate the performed changes because a ZSK has no associated DS - record in the parent zone. - - In a KSK rollover, new DS RR(s) must be created and stored in the - parent zone. In consequence, the child zone must contact its parent - zone and must notify it about the KSK change(s). - - Manual key rollover exists and works [3]. The key rollover is built - from two parts of different nature: - o An algorithm that generates new keys and signs the zone file. It - could be local to the zone - o The interaction between parent and child zones - - One example of manual key rollover is: - - - - -Guette & Courtay Expires February 5, 2005 [Page 3] - -Internet-Draft Automated Rollover Requirements August 2004 - - - o The child zone creates a new KSK - o The child zone waits for the creation of the DS RR in its parent - zone - o The child zone deletes the old key. - - In manual rollover, communications are managed by the zone - administrators and the security of these communications is out of - scope of DNSSEC. - - Automated key rollover should use a secure communication between - parent and child zones. This document concentrates on defining - interactions between entities present in key rollover process. - -3. Basic Requirements - - The main constraint to respect during a key rollover is that the - chain of trust MUST be preserved, even if a resolver retrieves some - RRs from recursive cache server. Every RR MUST be verifiable at any - time, every RRs exchanged during the rollover should be authenticated - and their integrity should be guaranteed. - - Two entities act during a KSK rollover: the child zone and its parent - zone. These zones are generally managed by different administrators. - These administrators should agree on some parameters like - availability of automated rollover, the maximum delay between - notification of changes in the child zone and the resigning of the - parent zone. The child zone needs to know this delay to schedule its - changes. - -4. Messages authentication and information exchanged - - Every exchanged message MUST be authenticated and the authentication - tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC - request with verifiable SIG records. - - Once the changes related to a KSK are made in a child zone, this zone - MUST notify its parent zone in order to create the new DS RR and - store this DS RR in parent zone file. - - The parent zone MUST receive all the child keys that needs the - creation of associated DS RRs in the parent zone. - - Some errors could occur during transmission between child zone and - parent zone. Key rollover solution MUST be fault tolerant, i.e. at - any time the rollover MUST be in a consistent state and all RRs MUST - be verifiable, even if an error occurs. That is to say that it MUST - remain a valid chain of trust. - - - - -Guette & Courtay Expires February 5, 2005 [Page 4] - -Internet-Draft Automated Rollover Requirements August 2004 - - -5. Emergency Rollover - - A key of a zone might be compromised and this key MUST be changed as - soon as possible. Fast changes could break the chain of trust. The - part of DNS tree having this zone as apex can become unverifiable, - but the break of the chain of trust is necessary if we want to no one - can use the compromised key to spoof DNS data. - - In case of emergency rollover, the administrators of parent and child - zones should create new key(s) and DS RR(s) as fast as possible in - order to reduce the time the chain of trust is broken. - -6. Other Resource Record concerned by automatic rollover - - NS records are also present at delegation point, so when the child - zone renews some NS RR, the corresponding records at delegation point - in parent zone (glue) MUST be updated. NS records are concerned by - rollover and this rollover could be automated too. In this case, - when the child zone notifies its parent zone that some NS records - have been changed, the parent zone MUST verify that these NS records - are present in child zone before doing any changes in its own zone - file. This allows to avoid inconsistency between NS records at - delegation point and NS records present in the child zone. - -7. Security consideration - - This document describes requirements to design an automated key - rollover in DNSSEC based on DNSSEC security. In the same way, as - plain DNSSEC, the automatic key rollover contains no mechanism - protecting against denial of service (DoS). The security level - obtain after an automatic key rollover, is the security level - provided by DNSSEC. - -8. Acknowledgments - - The authors want to acknowledge Francis Dupont, Mohsen Souissi, - Bernard Cousin, Bertrand L‰onard and members of IDsA project for - their contribution to this document. - -9 Normative References - - [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - - - -Guette & Courtay Expires February 5, 2005 [Page 5] - -Internet-Draft Automated Rollover Requirements August 2004 - - - [3] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practice-01 (work in - progress), May 2004. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [7] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-09 (work in progress), July - 2004. - - [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004. - - [9] Arends, R., "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in - progress), July 2004. - - -Authors' Addresses - - Gilles Guette - IRISA / INRIA - Campus de Beaulieu - 35042 Rennes CEDEX - FR - - EMail: gilles.guette@irisa.fr - URI: http://www.irisa.fr - - - Olivier Courtay - Thomson R&D - 1, avenue Belle Fontaine - 35510 Cesson S‰vign‰ CEDEX - FR - - EMail: olivier.courtay@thomson.net - - - - - -Guette & Courtay Expires February 5, 2005 [Page 6] - -Internet-Draft Automated Rollover Requirements August 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Guette & Courtay Expires February 5, 2005 [Page 7] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt deleted file mode 100644 index 1094275..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt +++ /dev/null @@ -1,505 +0,0 @@ - - -IETF DNSOP Working Group Y. Morishita -Internet-Draft JPRS -Expires: July 11, 2004 T. Jinmei - Toshiba - January 11, 2004 - - - Common Misbehavior against DNS Queries for IPv6 Addresses - draft-ietf-dnsop-misbehavior-against-aaaa-00.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 11, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - There is some known misbehavior of DNS authoritative servers when - they are queried for AAAA resource records. Such behavior can block - IPv4 communication which should actually be available, cause a - significant delay in name resolution, or even make a denial of - service attack. This memo describes details of the known cases and - discusses the effect of the cases. - -1. Introduction - - Many DNS clients (resolvers) that support IPv6 first search for AAAA - Resource Records (RRs) of a target host name, and then for A RRs of - - - -Morishita & Jinmei Expires July 11, 2004 [Page 1] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - the same name. This fallback mechanism is based on the DNS - specifications, which if not obeyed by authoritative servers can - produce unpleasant results. In some cases, for example, a web browser - fails to connect to a web server it could otherwise. In the following - sections, this memo describes some typical cases of the misbehavior - and its (bad) effects. - - Note that the misbehavior is not specific to AAAA RRs. In fact, all - known examples also apply to the cases of queries for MX, NS, and SOA - RRs. The authors even believe this can be generalized for all types - of queries other than those for A RRs. In this memo, however, we - concentrate on the case for AAAA queries, since the problem is - particularly severe for resolvers that support IPv6, which thus - affects many end users. Resolvers at end users normally send A and/or - AAAA queries only, and so the problem for the other cases is - relatively minor. - -2. Network Model - - In this memo, we assume a typical network model of name resolution - environment using DNS. It consists of three components; stub - resolvers, caching servers, and authoritative servers. A stub - resolver issues a recursive query to a caching server, which then - handles the entire name resolution procedure recursively. The caching - server caches the result of the query as well as sends the result to - the stub resolver. The authoritative servers respond to queries for - names for which they have the authority, normally in a non-recursive - manner. - -3. Expected Behavior - - Suppose that an authoritative server has an A RR but not a AAAA RR - for a host name. Then the server should return a response to a query - for a AAAA RR of the name with the RCODE being 0 (indicating no - error) and with an empty answer section [1]. Such a response - indicates that there is at least one RR of a different type than AAAA - for the queried name, and the stub resolver can then look for A RRs. - - This way, the caching server can cache the fact that the queried name - does not have a AAAA RR (but may have other types of RRs), and thus - can improve the response time to further queries for a AAAA RR of the - name. - -4. Problematic Behaviors - - There are some known cases at authoritative servers that do not - conform to the expected behavior. This section describes those - problematic cases. - - - -Morishita & Jinmei Expires July 11, 2004 [Page 2] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -4.1 Return NXDOMAIN - - This type of server returns a response with the RCODE being 3 - (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any - RRs of any type for the queried name. - - With this response, the stub resolver may immediately give up and - never fall back. Even if the resolver retries with a query for an A - RR, the negative response for the name has been cached in the caching - server, and the caching server will simply return the negative - response. As a result, the stub resolver considers this as a fatal - error in name resolution. - - There have been several known examples of this behavior, but all the - examples that the authors know have changed their behavior as of this - writing. - -4.2 Return NOTIMP - - Other authoritative servers return a response with the RCODE being 4 - (NOTIMP), indicating the servers do not support the requested type of - query. - - This case is less harmful than the previous one; if the stub resolver - falls back to querying for an A RR, the caching server will process - the query correctly and return an appropriate response. - - In this case, the caching server does not cache the fact that the - queried name has no AAAA RR, resulting in redundant queries for AAAA - RRs in the future. The behavior will waste network bandwidth and - increase the load of the authoritative server. - - Using SERVFAIL or FORMERR would cause the same effect, though the - authors have not seen such implementations yet. - -4.3 Return a Broken Response - - Another different type of authoritative servers returns broken - responses to AAAA queries. A known behavior of this category is to - return a response whose RR type is AAAA, but the length of the RDATA - is 4 bytes. The 4-byte data looks like the IPv4 address of the - queried host name. That is, the RR in the answer section would be - described like this: - - www.bad.example. 600 IN AAAA 192.0.2.1 - - which is, of course, bogus (or at least meaningless). - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 3] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - A widely deployed caching server implementation transparently returns - the broken response (as well as caches it) to the stub resolver. - Another known server implementation parses the response by - themselves, and sends a separate response with the RCODE being 2 - (SERVFAIL). - - In either case, the broken response does not affect queries for an A - RR of the same name. If the stub resolver falls back to A queries, it - will get an appropriate response. - - The latter case, however, causes the same bad effect as that - described in the previous section: redundant queries for AAAA RRs. - -4.4 Make Lame Delegation - - Some authoritative servers respond to AAAA queries in a way causing - lame delegation. In this case the parent zone specifies that the - authoritative server should have the authority of a zone, but the - server does not return an authoritative response for AAAA queries - within the zone (i.e., the AA bit in the response is not set). On the - other hand, the authoritative server returns an authoritative - response for A queries. - - When a caching server asks the server for AAAA RRs in the zone, it - recognizes the delegation is lame, and return a response with the - RCODE being 2 (SERVFAIL) to the stub resolver. - - Furthermore, some caching servers record the authoritative server as - lame for the zone and will not use it for a certain period of time. - With this type of caching server, even if the stub resolver falls - back to querying for an A RR, the caching server will simply return a - response with the RCODE being SERVFAIL, since all the servers are - known to be "lame." - - There is also an implementation that relaxes the behavior a little - bit. It basically tries to avoid using the lame server, but still - continues to try it as a last resort. With this type of caching - server, the stub resolver will get a correct response if it falls - back after SERVFAIL. However, this still causes redundant AAAA - queries as explained in the previous sections. - -4.5 Ignore Queries for AAAA - - Some authoritative severs seem to ignore queries for a AAAA RR, - causing a delay at the stub resolver to fall back to a query for an A - RR. This behavior may even cause a fatal timeout at the resolver. - - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 4] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -5. Security Considerations - - The CERT/CC pointed out that the response with NXDOMAIN described in - Section 4.1 can be used for a denial of service attack [2]. The same - argument applies to the case of "lame delegation" described in - Section 4.4 with a certain type of caching server. - -6. Acknowledgements - - Erik Nordmark encouraged the authors to publish this document as an - Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary - version of this document. Pekka Savola carefully reviewed a previous - version and provided detailed comments. - -Informative References - - [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC - 1034, November 1987. - - [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from - AAAA queries could cause denial-of-service conditions", March - 2003, <http://www.kb.cert.org/vuls/id/714121>. - - -Authors' Addresses - - MORISHITA Orange Yasuhiro - Research and Development Department, Japan Registry Service Co.,Ltd. - Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi - Chiyoda-ku, Tokyo 101-0052 - Japan - - EMail: yasuhiro@jprs.co.jp - - - JINMEI Tatuya - Corporate Research & Development Center, Toshiba Corporation - 1 Komukai Toshiba-cho, Saiwai-ku - Kawasaki-shi, Kanagawa 212-8582 - Japan - - EMail: jinmei@isl.rdc.toshiba.co.jp - -Appendix A. Live Examples - - In this appendix, we show concrete implementations and domain names - that may cause problematic cases so that the behavior can be - reproduced in a practical environment. The examples are for - - - -Morishita & Jinmei Expires July 11, 2004 [Page 5] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - informational purposes only, and the authors do not intend to accuse - any implementations or zone administrators. - - The behavior described in Section 4.2 (return NOTIMP) can be found by - looking for a AAAA RR of www.css.vtext.com at 66.174.3.4. - - The behavior described in Section 4.3 (broken responses) can be seen - by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an - alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior - can be found with the name "vip.alt.ihp.sony.co.jp," an alias of - "www.sony.co.jp," at 210.139.255.204. - - The behavior described in Section 4.4 (lame delegation) can be found - by querying for a AAAA RR of "www.ual.com" at 209.87.113.4. - - The behavior described in Section 4.5 (ignore queries) can be seen by - trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an - alias of "ad.jp.doubleclick.net," at 210.153.90.9. - - Many authoritative server implementations show the expected behavior - described in Section 3. Some DNS load balancers reportedly have a - problematic behavior shown in Section 4, but the authors do not have - a concrete example. The CERT/CC provides a list of implementations - that behave as described in Section 4.1 [2]. - - The BIND9 caching server implementation is an example of the latter - cases described in Section 4.3 and Section 4.4, respectively. The - BIND8 caching server implementation is an example of the former case - described in Section 4.3. As for the issue shown in Section 4.4, - BIND8 caching servers prior to 8.3.5 show the behavior described as - the former case in this section. The versions 8.3.5 and later of - BIND8 caching server behave like the BIND9 caching server - implementation with this matter. - - Regarding resolver implementations, the authors are only familiar - with the ones derived from the BIND implementation. These - implementations always fall back regardless of the RCODE; NXDOMAIN, - NOTIMP, or SERVFAIL. It even falls back when getting a broken - response. However, the behavior does not help the situation in the - NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also - causes a fatal error at the resolver side if the resolver is using - some older versions of BIND8 caching server. - - The authors hear that a stub resolver routine implemented in some web - browsers interprets the broken response described in Section 4.3 as a - fatal error and does not fall back to A queries. However, we have not - confirmed this information. - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 6] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -Appendix B. Change History - - Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are: - - o Made a separate appendix and moved live examples to appendix so - that we can remove them when this document is (ever) officially - published. - - o Revised some live examples based on the recent status. - - o Noted in introduction that the misbehavior is not specific to AAAA - and that this document still concentrates on the AAAA case. - - o Changed the section title of "delegation loop" to "lame - delegation" in order to reflect the essential point of the issue. - Wording on this matter was updated accordingly. - - o Updated the Acknowledgements list. - - o Changed the reference category from normative to informative (this - is an informational document after all). - - o Changed the draft name to an IETF dnsop working group document (as - agreed). - - o Applied several editorial fixes. - - - - - - - - - - - - - - - - - - - - - - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 7] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Morishita & Jinmei Expires July 11, 2004 [Page 8] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 9] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt deleted file mode 100644 index f6ece88..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt +++ /dev/null @@ -1,485 +0,0 @@ - DNSOP Working Group Paul Vixie, ISC (Ed.) - INTERNET-DRAFT Akira Kato, WIDE - <draft-ietf-dnsop-respsize-01.txt> July, 2004 - - - DNS Response Size Issues - - - 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 we are aware have been or will be disclosed, and any of which - we 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. - - - Copyright Notice - - - Copyright (C) The Internet Society (2003-2004). All Rights Reserved. - - - - - - Abstract - - - With a mandated default minimum maximum message size of 512 octets, - the DNS protocol presents some special problems for zones wishing to - expose a moderate or high number of authority servers (NS RRs). This - document explains the operational issues caused by, or related to - this response size limit. - - - - - - - Expires December 2004 [Page 1] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 1 - Introduction and Overview - - - 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 - octets. Even though this limitation was due to the required minimum UDP - reassembly limit for IPv4, it is a hard DNS protocol limit and is not - implicitly relaxed by changes in transport, for example to IPv6. - - - 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger - responses by mutual agreement of the requestor and responder. However, - deployment of EDNS0 cannot be expected to reach every Internet resolver - in the short or medium term. The 512 octet message size limit remains - in practical effect at this time. - - - 1.3. Since DNS responses include a copy of the request, the space - available for response data is somewhat less than the full 512 octets. - For negative responses, there is rarely a space constraint. For - positive and delegation responses, though, every octet must be carefully - and sparingly allocated. This document specifically addresses - delegation response sizes. - - - 2 - Delegation Details - - - 2.1. A delegation response will include the following elements: - - - Header Section: fixed length (12 octets) - Question Section: original query (name, class, type) - Answer Section: (empty) - Authority Section: NS RRset (nameserver names) - Additional Section: A and AAAA RRsets (nameserver addresses) - - - 2.2. If the total response size would exceed 512 octets, and if the data - that would not fit was in the question, answer, or authority section, - then the TC bit will be set (indicating truncation) which may cause the - requestor to retry using TCP, depending on what information was present - and what was omitted. If a retry using TCP is needed, the total cost of - the transaction is much higher. - - - 2.3. RRsets are never sent partially, so if truncation occurs, entire - RRsets are omitted. Note that the authority section consists of a - single RRset. It is absolutely essential that truncation not occur in - the authority section. - - - - - - - - - Expires December 2004 [Page 2] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 2.4. DNS label compression allows a domain name to be instantiated only - once per DNS message, and then referenced with a two-octet "pointer" - from other locations in that same DNS message. If all nameserver names - in a message are similar (for example, all ending in ".ROOT- - SERVERS.NET"), then more space will be available for uncompressable data - (such as nameserver addresses). - - - 2.5. The query name can be as long as 255 characters of presentation - data, which can be up to 256 octets of network data. In this worst case - scenario, the question section will be 260 octets in size, which would - leave only 240 octets for the authority and additional sections (after - deducting 12 octets for the fixed length header.) - - - 2.6. Average and maximum question section sizes can be predicted by the - zone owner, since they will know what names actually exist, and can - measure which ones are queried for most often. For cost and performance - reasons, the majority of requests should be satisfied without truncation - or TCP retry. - - - 2.7. Requestors who deliberately send large queries to force truncation - are only increasing their own costs, and cannot effectively attack the - resources of an authority server since the requestor would have to retry - using TCP to complete the attack. An attack that always used TCP would - have a lower cost. - - - 2.8. The minimum useful number of address records is two, since with - only one address, the probability that it would refer to an unreachable - server is too high. Truncation which occurs after two address records - have been added to the additional data section is therefore less - operationally significant than truncation which occurs earlier. - - - 2.9. The best case is no truncation. (This is because many requestors - will retry using TCP by reflex, without considering whether the omitted - data was actually necessary.) - - - - - - - - - - - - - - - - Expires December 2004 [Page 3] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 3 - Analysis - - - 3.1. An instrumented protocol trace of a best case delegation response - follows. Note that 13 servers are named, and 13 addresses are given. - This query was artificially designed to exactly reach the 512 octet - limit. - - - ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 - ;; QUERY SECTION: - ;; [23456789.123456789.123456789.\ - 123456789.123456789.123456789.com A IN] ;; @80 - - - ;; AUTHORITY SECTION: - com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 - com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 - com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 - com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 - com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 - com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 - com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 - com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 - com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 - com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 - com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 - com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 - com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 - - - ;; ADDITIONAL SECTION: - A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 - B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 - C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 - D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 - E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 - F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 - G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 - H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 - I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 - J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 - K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 - L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 - M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 - - - ;; MSG SIZE sent: 80 rcvd: 512 - - - - - - - Expires December 2004 [Page 4] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 3.2. For longer query names, the number of address records supplied will - be lower. Furthermore, it is only by using a common parent name (which - is GTLD-SERVERS.NET in this example) that all 13 addresses are able to - fit. The following output from a response simulator demonstrates these - properties: - - - % perl respsize.pl 13 13 0 - common name, average case: msg:303 nsaddr#13 (green) - common name, worst case: msg:495 nsaddr# 1 (red) - uncommon name, average case: msg:457 nsaddr# 3 (orange) - uncommon name, worst case: msg:649(*) nsaddr# 0 (red) - % perl respsize.pl 13 13 2 - common name, average case: msg:303 nsaddr#11 (orange) - common name, worst case: msg:495 nsaddr# 1 (red) - uncommon name, average case: msg:457 nsaddr# 2 (orange) - uncommon name, worst case: msg:649(*) nsaddr# 0 (red) - - - (Note: The response simulator program is shown in Section 5.) - - - Here we use the term "green" if all address records could fit, or - "orange" if two or more could fit, or "red" if fewer than two could fit. - It's clear that without a common parent for nameserver names, much space - would be lost. - - - We're assuming an average query name size of 64 since that is the - typical average maximum size seen in trace data at the time of this - writing. If Internationalized Domain Name (IDN) or any other technology - which results in larger query names be deployed significantly in advance - of EDNS, then more new measurements and new estimates will have to be - made. - - - 4 - Conclusions - - - 4.1. The current practice of giving all nameserver names a common parent - (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS - responses and allows for more nameservers to be enumerated than would - otherwise be possible. (Note that in this case it is wise to serve the - common parent domain's zone from the same servers that are named within - it, in order to limit external dependencies when all your eggs are in a - single basket.) - - - 4.2. Thirteen (13) seems to be the effective maximum number of - nameserver names usable traditional (non-extended) DNS, assuming a - common parent domain name, and assuming that additional-data truncation - is undesirable in the average case. - - - - - Expires December 2004 [Page 5] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a - prototypical delegation that currently contains thirteen (13) IPv4 - nameserver addresses (A RRs) for thirteen (13) nameserver names under a - common parent, would not have a significant negative operational impact - on the domain name system. - - - 5 - Source Code - - - #!/usr/bin/perl -w - - - $asize = 2+2+2+4+2+4; - $aaaasize = 2+2+2+4+2+16; - ($nns, $na, $naaaa) = @ARGV; - test("common", "average", common_name_average($nns), - $na, $naaaa); - test("common", "worst", common_name_worst($nns), - $na, $naaaa); - test("uncommon", "average", uncommon_name_average($nns), - $na, $naaaa); - test("uncommon", "worst", uncommon_name_worst($nns), - $na, $naaaa); - exit 0; - - - sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_; - my $nglue = numglue($msg, $na, $naaaa); - printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n", - $namekind, $casekind, - $msg, ($msg > 512) ? "(*)" : " ", - $nglue, ($nglue == $na + $naaaa) ? "green" - : ($nglue >= 2) ? "orange" - : "red"; - } - - - sub pnum { my ($num, $tot) = @_; - return sprintf "%3d%s", - } - - - sub numglue { my ($msg, $na, $naaaa) = @_; - my $space = ($msg > 512) ? 0 : (512 - $msg); - my $num = 0; - - - while ($space && ($na || $naaaa )) { - if ($na) { - if ($space >= $asize) { - $space -= $asize; - - - - - Expires December 2004 [Page 6] - INTERNET-DRAFT June 2003 RESPSIZE - - - - $num++; - } - $na--; - } - if ($naaaa) { - if ($space >= $aaaasize) { - $space -= $aaaasize; - $num++; - } - $naaaa--; - } - } - return $num; - } - - - sub msgsize { my ($qname, $nns, $nsns) = @_; - return 12 + # header - $qname+2+2 + # query - 0 + # answer - $nns * (4+2+2+4+2+$nsns); # authority - } - - - sub average_case { my ($nns, $nsns) = @_; - return msgsize(64, $nns, $nsns); - } - - - sub worst_case { my ($nns, $nsns) = @_; - return msgsize(256, $nns, $nsns); - } - - - sub common_name_average { my ($nns) = @_; - return 15 + average_case($nns, 2); - } - - - sub common_name_worst { my ($nns) = @_; - return 15 + worst_case($nns, 2); - } - - - sub uncommon_name_average { my ($nns) = @_; - return average_case($nns, 15); - } - - - sub uncommon_name_worst { my ($nns) = @_; - return worst_case($nns, 15); - } - - - - - Expires December 2004 [Page 7] - INTERNET-DRAFT June 2003 RESPSIZE - - - - Security Considerations - - - The recommendations contained in this document have no known security - implications. - - - IANA Considerations - - - This document does not call for changes or additions to any IANA - registry. - - - IPR Statement - - - Copyright (C) The Internet Society (2003-2004). This document is - subject to the rights, licenses and restrictions contained in BCP 78, - and except as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR - IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - Authors' Addresses - - - Paul Vixie - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - vixie@isc.org - - - Akira Kato - University of Tokyo, Information Technology Center - 2-11-16 Yayoi Bunkyo - Tokyo 113-8658, JAPAN - +81 3 5841 2750 - kato@wide.ad.jp - - - - - - - - - - - Expires December 2004 [Page 8]
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt deleted file mode 100644 index b593c57..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt +++ /dev/null @@ -1,617 +0,0 @@ - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: January 16, 2005 D. Conrad - Nominum, Inc. - July 18, 2004 - - - Identifying an Authoritative Name `Server - draft-ietf-dnsop-serverid-02 - -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 January 16, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid. Existing ad - - - -Woolf & Conrad Expires January 16, 2005 [Page 1] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - - 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 disadvantasges, and to - characterize an improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 2] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -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 January 16, 2005 [Page 3] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -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 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 (e.g., as generated by tools such - as "traceroute"), etc., can end up going to a different server than - that which receives the DNS queries. - - 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 January 16, 2005 [Page 4] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -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 re- - definable string which defaults to the version of the server - responding. - -3.1 Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - 1. This 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. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - 3. 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. - 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 - - - -Woolf & Conrad Expires January 16, 2005 [Page 5] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - - 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 anyway. 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 January 16, 2005 [Page 6] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -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. - 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 January 16, 2005 [Page 7] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -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 January 16, 2005 [Page 8] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -6. Security Considerations - - Providing identifying information as to which server is responding - 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 January 16, 2005 [Page 9] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -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 draft 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 January 16, 2005 [Page 10] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires January 16, 2005 [Page 11] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt deleted file mode 100644 index 423a119..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt +++ /dev/null @@ -1,951 +0,0 @@ - - -IPSECKEY WG M. Richardson -Internet-Draft SSW -|Expires: August 1, 2004 February 2004 - - - A Method for Storing IPsec Keying Material in DNS -| draft-ietf-ipseckey-rr-09.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 1, 2004. - -Copyright Notice - -| Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - -| This document describes a new resource record for Domain Name System -| (DNS). This record may be used to store public keys for use in IP -| security (IPsec) systems. The record also includes provisions for -| indicating what system should be contacted when establishing an IPsec -| tunnel with the entity in question. - - This record replaces the functionality of the sub-type #1 of the KEY - Resource Record, which has been obsoleted by RFC3445. - - - - - - - -|Richardson Expires August 1, 2004 [Page 1] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 -| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3 -| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 -| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5 -| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5 -| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5 -| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5 -| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6 -| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6 -| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6 -| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8 -| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8 -| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 -| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 -| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10 -| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 -| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13 -| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 -| Normative references . . . . . . . . . . . . . . . . . . . . . 15 -| Non-normative references . . . . . . . . . . . . . . . . . . . 16 -| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 -| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 2] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -1. Introduction - - It postulated that there is an end system desiring to establish an - IPsec tunnel with some remote entity on the network. This system, - having only a DNS name of some kind (forward, reverse or even - user@FQDN) needs a public key to authenticate the remote entity. It - also desires some guidance about whether to contact the entity - directly, or whether to contact another entity, as the gateway to - that desired entity. - - The IPSECKEY RR provides a storage mechanism for such items as the - public key, and the gateway information. - - The type number for the IPSECKEY RR is TBD. - -1.1 Overview - - The IPSECKEY resource record (RR) is used to publish a public key - that is to be associated with a Domain Name System (DNS) name for use - with the IPsec protocol suite. This can be the public key of a - host, network, or application (in the case of per-port keying). - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 [7]. - -|1.2 Use of reverse (in-addr.arpa) map - -| Often a security gateway will only have access to the IP address to -| which communication is desired. It will not know the forward name. -| As such, it will frequently be the case that the IP address will be -| used an index into the reverse map. - -| The lookup is done in the usual fashion as for PTR records. The IP -| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up -| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be -| followed. - -| Note: even when the IPsec function is the end-host, often only the -| application will know the forward name used. While the case where -| the application knows the forward name is common, the user could -| easily have typed in a literal IP address. This storage mechanism -| does not preclude using the forward name when it is available, but -| does not require it. - -|1.3 Usage Criteria - - An IPSECKEY resource record SHOULD be used in combination with DNSSEC - - - -|Richardson Expires August 1, 2004 [Page 3] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - unless some other means of authenticating the IPSECKEY resource - record is available. - - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence of - multiple gateways and the need to rollover keys. - - This resource record is class independent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 4] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -2. Storage formats - -2.1 IPSECKEY RDATA format - - The RDATA for an IPSECKEY RR consists of a precedence value, a - gateway type, a public key, algorithm type, and an optional gateway - address. - - 0 1 2 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - -2.2 RDATA format - precedence - - This is an 8-bit precedence for this record. This is interpreted in - the same way as the PREFERENCE field described in section 3.3.9 of - RFC1035 [2]. - - Gateways listed in IPSECKEY records with lower precedence are to be - attempted first. Where there is a tie in precedence, the order - should be non-deterministic. - -2.3 RDATA format - gateway type - - The gateway type field indicates the format of the information that - is stored in the gateway field. - - The following values are defined: - - 0 No gateway is present - - 1 A 4-byte IPv4 address is present - - 2 A 16-byte IPv6 address is present - - 3 A wire-encoded domain name is present. The wire-encoded format is - self-describing, so the length is implicit. The domain name MUST - NOT be compressed. (see section 3.3 of RFC1035 [2]). - - - - -|Richardson Expires August 1, 2004 [Page 5] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -2.4 RDATA format - algorithm type - - The algorithm type field identifies the public key's cryptographic - algorithm and determines the format of the public key field. - - A value of 0 indicates that no key is present. - - The following values are defined: - - 1 A DSA key is present, in the format defined in RFC2536 [10] - - 2 A RSA key is present, in the format defined in RFC3110 [11] - - -2.5 RDATA format - gateway - - The gateway field indicates a gateway to which an IPsec tunnel may be - created in order to reach the entity named by this resource record. - - There are three formats: - - A 32-bit IPv4 address is present in the gateway field. The data - portion is an IPv4 address as described in section 3.4.1 of RFC1035 - [2]. This is a 32-bit number in network byte order. - - A 128-bit IPv6 address is present in the gateway field. The data - portion is an IPv6 address as described in section 2.2 of RFC3596 - [13]. This is a 128-bit number in network byte order. - - The gateway field is a normal wire-encoded domain name, as described - in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. - -2.6 RDATA format - public keys - - Both of the public key types defined in this document (RSA and DSA) - inherit their public key formats from the corresponding KEY RR - formats. Specifically, the public key field contains the algorithm- - specific portion of the KEY RR RDATA, which is all of the KEY RR DATA - after the first four octets. This is the same portion of the KEY RR - that must be specified by documents that define a DNSSEC algorithm. - Those documents also specify a message digest to be used for - generation of SIG RRs; that specification is not relevant for - IPSECKEY RR. - - Future algorithms, if they are to be used by both DNSSEC (in the KEY - RR) and IPSECKEY, are likely to use the same public key encodings in - both records. Unless otherwise specified, the IPSECKEY public key - field will contain the algorithm-specific portion of the KEY RR RDATA - - - -|Richardson Expires August 1, 2004 [Page 6] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - for the corresponding algorithm. The algorithm must still be - designated for use by IPSECKEY, and an IPSECKEY algorithm type number - (which might be different than the DNSSEC algorithm number) must be - assigned to it. - - The DSA key format is defined in RFC2536 [10] - - The RSA key format is defined in RFC3110 [11], with the following - changes: - - The earlier definition of RSA/MD5 in RFC2065 limited the exponent and - modulus to 2552 bits in length. RFC3110 extended that limit to 4096 - bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on - RSA public keys, other than the 65535 octet limit imposed by the two- - octet length encoding. This length extension is applicable only to - IPSECKEY and not to KEY RRs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 7] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -3. Presentation formats - -3.1 Representation of IPSECKEY RRs - - IPSECKEY RRs may appear in a zone data master file. The precedence, - gateway type and algorithm and gateway fields are REQUIRED. The - base64 encoded public key block is OPTIONAL; if not present, then the - public key field of the resource record MUST be construed as being - zero octets in length. - - The algorithm field is an unsigned integer. No mnemonics are - defined. - - If no gateway is to be indicated, then the gateway type field MUST be - zero, and the gateway field MUST be "." - - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see RFC3548 [6] Section 5.2. - - The general presentation for the record as as follows: - - IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) - - -3.2 Examples - - An example of a node 192.0.2.38 that will accept IPsec tunnels on its - own behalf. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has published its key only. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has delegated authority to the - node 192.0.2.3. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - -|Richardson Expires August 1, 2004 [Page 8] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - An example of a node, 192.0.1.38 that has delegated authority to the - node with the identity "mygateway.example.com". - - 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has - delegated authority to the node 2001:0DB8:c000:0200:2::1 - - $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. - 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 9] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -4. Security Considerations - - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. - - The IPSECKEY resource record contains information that SHOULD be - communicated to the end client in an integral fashion - i.e. free - from modification. The form of this channel is up to the consumer of - the data - there must be a trust relationship between the end - consumer of this resource record and the server. This relationship - may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to - another secure source, a secure local channel on the host, or some - combination of the above. - - The keying material provided by the IPSECKEY resource record is not - sensitive to passive attacks. The keying material may be freely - disclosed to any party without any impact on the security properties - of the resulting IPsec session: IPsec and IKE provide for defense - against both active and passive attacks. - - Any derivative standard that makes use of this resource record MUST - carefully document their trust model, and why the trust model of - DNSSEC is appropriate, if that is the secure channel used. - -4.1 Active attacks against unsecured IPSECKEY resource records - - This section deals with active attacks against the DNS. These - attacks require that DNS requests and responses be intercepted and - changed. DNSSEC is designed to defend against attacks of this kind. - - The first kind of active attack is when the attacker replaces the - keying material with either a key under its control or with garbage. - - If the attacker is not able to mount a subsequent man-in-the-middle - attack on the IKE negotiation after replacing the public key, then - this will result in a denial of service, as the authenticator used by - IKE would fail. - - If the attacker is able to both to mount active attacks against DNS - and is also in a position to perform a man-in-the-middle attack on - IKE and IPsec negotiations, then the attacker will be in a position - to compromise the resulting IPsec channel. Note that an attacker - must be able to perform active DNS attacks on both sides of the IKE - negotiation in order for this to succeed. - - The second kind of active attack is one in which the attacker - replaces the the gateway address to point to a node under the - attacker's control. The attacker can then either replace the public - - - -|Richardson Expires August 1, 2004 [Page 10] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - key or remove it, thus providing an IPSECKEY record of its own to - match the gateway address. - - This later form creates a simple man-in-the-middle since the attacker - can then create a second tunnel to the real destination. Note that, - as before, this requires that the attacker also mount an active - attack against the responder. - - Note that the man-in-the-middle can not just forward cleartext - packets to the original destination. While the destination may be - willing to speak in the clear, replying to the original sender, the - sender will have already created a policy expecting ciphertext. - Thus, the attacker will need to intercept traffic from both sides. - In some cases, the attacker may be able to accomplish the full - intercept by use of Network Addresss/Port Translation (NAT/NAPT) - technology. - -| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY -| RR only applies to cases where the gateway field of the IPSECKEY RR -| indicates a different entity than the owner name of the IPSECKEY RR. - -| An active attack on the DNS that caused the wrong IP address to be -| retrieved (via forged A RR), and therefore the wrong QNAME to be -| queried would also result in a man-in-the-middle attack. This -| situation exists independantly of whether or not the IPSECKEY RR is -| used. - -| In cases where the end-to-end integrity of the IPSECKEY RR is -| suspect, the end client MUST restrict its use of the IPSECKEY RR to -| cases where the RR owner name matches the content of the gateway -| field. - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 11] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -5. IANA Considerations - - This document updates the IANA Registry for DNS Resource Record Types - by assigning type X to the IPSECKEY record. - - This document creates two new IANA registries, both specific to the - IPSECKEY Resource Record: - - This document creates an IANA registry for the algorithm type field. - - Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 - through 255 can be assigned by IETF Consensus (see RFC2434 [5]). - - This document creates an IANA registry for the gateway type field. - - Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type - numbers 4 through 255 can be assigned by Standards Action (see - RFC2434 [5]). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 12] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -6. Intellectual Property Claims - - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication 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 implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 13] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -7. Acknowledgments - - My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob - Austein, and Olafur Gurmundsson who reviewed this document carefully. - Additional thanks to Olafur Gurmundsson for a reference - implementation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 14] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Normative references - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - [4] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 15] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Non-normative references - - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [8] Piper, D., "The Internet IP Security Domain of Interpretation - for ISAKMP", RFC 2407, November 1998. - - [9] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October 2003. - - -Author's Address - - Michael C. Richardson - Sandelman Software Works - 470 Dawson Avenue - Ottawa, ON K1Z 5V7 - CA - - EMail: mcr@sandelman.ottawa.on.ca - URI: http://www.sandelman.ottawa.on.ca/ - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 16] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Full Copyright Statement - -| Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 17] |
