diff options
Diffstat (limited to 'contrib/bind9/doc/draft')
14 files changed, 14696 insertions, 1 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt new file mode 100644 index 0000000..07749d9 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt @@ -0,0 +1,674 @@ + + + + +DNSEXT M. Stapp +Internet-Draft Cisco Systems, Inc. +Expires: September 1, 2006 T. Lemon + Nominum, Inc. + A. Gustafsson + Araneus Information Systems Oy + February 28, 2006 + + + A DNS RR for Encoding DHCP Information (DHCID RR) + <draft-ietf-dnsext-dhcid-rr-12.txt> + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on September 1, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + It is possible for DHCP clients to attempt to update the same DNS + FQDN or attempt to update a DNS FQDN that has been added to the DNS + for another purpose 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 + + + +Stapp, et al. Expires September 1, 2006 [Page 1] + +Internet-Draft The DHCID RR February 2006 + + + Conflicts" [1] proposes storing client identifiers in the DNS to + unambiguously associate domain names with the DHCP clients to which + they refer. This memo defines a distinct RR type for this purpose + for use by DHCP clients and servers, the "DHCID" RR. + + +Table of Contents + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 3 + 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4 + 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4 + 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4 + 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5 + 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5 + 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5 + 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6 + 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 + 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 + 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7 + 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires September 1, 2006 [Page 2] + +Internet-Draft The DHCID RR February 2006 + + +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 [6] [10] 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 or a DHCP client attempts to use a name added for another + purpose. 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 obscure potentially sensitive client identifying + information, the data stored is the result of a one-way SHA-256 hash + computation. The hash includes information from the DHCP client's + 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. + + +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. + +3.1. DHCID RDATA format + + The RDATA section of a DHCID RR in transmission contains RDLENGTH + octets 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 + + + +Stapp, et al. Expires September 1, 2006 [Page 3] + +Internet-Draft The DHCID RR February 2006 + + + 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 2-octet identifier type, in network byte order, + followed by a 1-octet digest type, followed by one or more octets + representing the actual identifier: + + < 2 octets > Identifier type code + < 1 octet > Digest type code + < n octets > Digest (length depends on digest type) + +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 3548 [7]. 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 Identifier Type Codes + + The DHCID RR Identifier Type Code specifies what data from the DHCP + client's request was used as input into the hash function. The + identifier type codes are defined in a registry maintained by IANA, + as specified in Section 7. The initial list of assigned values for + the identifier type code is: + + 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6]. + 0x0001 = The data octets (i.e., the Type and Client-Identifier + fields) from a DHCPv4 client's Client Identifier option [9]. + 0x0002 = The client's DUID (i.e., the data octets 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. The DHCID RR Digest Type Code + + The DHCID RR Digest Type Code is an identifier for the digest + algorithm used. The digest is calculated over an identifier and the + canonical FQDN as described in the next section. + + The digest type codes are defined in a registry maintained by IANA, + as specified in Section 7. The initial list of assigned values for + the digest type codes is: value 0 is reserved and value 1 is SHA-256. + + + +Stapp, et al. Expires September 1, 2006 [Page 4] + +Internet-Draft The DHCID RR February 2006 + + + Reserving other types requires IETF standards action. Defining new + values will also require IETF standards action to document how DNS + updaters are to deal with multiple digest types. + +3.5. Computation of the RDATA + + The DHCID RDATA is formed by concatenating the 2-octet identifier + type code with variable-length data. + + The RDATA for all type codes other than 0xffff, which is reserved for + future expansion, is formed by concatenating the 2-octet identifier + type code, the 1-octet digest type code, and the digest value (32 + octets for SHA-256). + + < identifier-type > < digest-type > < digest > + + The input to the digest hash function is defined to be: + + digest = SHA-256(< identifier > < FQDN >) + + The FQDN is represented in the buffer in unambiguous canonical form + as described in RFC 4034 [8], section 6.1. The identifier type code + and the identifier are related as specified in Section 3.3: the + identifier type code describes the source of the identifier. + + A DHCPv4 updater uses the 0x0002 type code if a Client Identifier + option is present in the DHCPv4 messages and it is encoded as + specified in [12]. Otherwise, the updater uses 0x0001 if a Client + Identifier option is present and 0x0000 if not. + + A DHCPv6 updater always uses the 0x0002 type code. + +3.5.1. Using the Client's DUID + + When the updater is using the Client's DUID (either from a DHCPv6 + Client Identifier option or from a portion of the DHCPv4 Client + Identifier option encoded as specified in [12]), the first two octets + of the DHCID RR MUST be 0x0002, in network byte order. The third + octet is the digest type code (1 for SHA-256). The rest of the DHCID + RR MUST contain the results of computing the SHA-256 hash across the + octets of the DUID followed by the FQDN. + +3.5.2. Using the Client Identifier Option + + When the updater is using the DHCPv4 Client Identifier option sent by + the client in its DHCPREQUEST message, the first two octets of the + DHCID RR MUST be 0x0001, in network byte order. The third octet is + the digest type code (1 for SHA-256). The rest of the DHCID RR MUST + + + +Stapp, et al. Expires September 1, 2006 [Page 5] + +Internet-Draft The DHCID RR February 2006 + + + contain the results of computing the SHA-256 hash across the data + octets (i.e., the Type and Client-Identifier fields) of the option, + followed by the FQDN. + +3.5.3. Using the Client's htype and chaddr + + When the updater is using the client's link-layer address as the + identifier, the first two octets of the DHCID RDATA MUST be zero. + The third octet is the digest type code (1 for SHA-256). To generate + the rest of the resource record, the updater computes a one-way hash + using the SHA-256 algorithm across a buffer containing the client's + network hardware type, link-layer address, and the FQDN data. + Specifically, the first octet 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 octets of the + 'chaddr' field in the client's DHCPREQUEST message follow, in the + same order in which the octets appear in the DHCPREQUEST message. + The number of significant octets in the 'chaddr' field is specified + in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as + specified above, follows. + +3.6. Examples + +3.6.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 + octets to zero, the 1-octet digest type to 1 for SHA-256, and + performing an SHA-256 hash computation across a buffer containing the + Ethernet MAC type octet, 0x01, the six octets of MAC address, and the + domain name (represented as specified in Section 3.5). + + client.example.com. A 10.0.0.1 + client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V + ytcKD//7es/deY= ) + + If the DHCID RR type is not supported, the RDATA would be encoded + [13] as: + + \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283 + fffedeb3f75e6 ) + +3.6.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 + + + +Stapp, et al. Expires September 1, 2006 [Page 6] + +Internet-Draft The DHCID RR February 2006 + + + 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 octets to the value 0x0001, the 1-octet digest + type to 1 for SHA-256, and performing a SHA-256 hash computation + across a buffer containing the seven octets from the client-id option + and the FQDN (represented as specified in Section 3.5). + + chi.example.com. A 10.0.12.99 + chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW + L3b/NaiUDlW2No= ) + + If the DHCID RR type is not supported, the RDATA would be encoded + [13] as: + + \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd + 6a2503956d8da ) + +3.6.3. Example 3 + + A DHCP server allocates the IPv6 address 2000::1234:5678 to a client + which included the DHCPv6 client-identifier option data 00:01:00:06: + 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server + updates the name "chi6.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 octets to the + value 0x0002, the 1-octet digest type to 1 for SHA-256, and + performing a SHA-256 hash computation across a buffer containing the + 14 octets from the client-id option and the FQDN (represented as + specified in Section 3.5). + + chi6.example.com. AAAA 2000::1234:5678 + chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l + OjxfNuVAA2kjEA= ) + + If the DHCID RR type is not supported, the RDATA would be encoded + [13] as: + + \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd + b95000da48c40 ) + + +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. + + + +Stapp, et al. Expires September 1, 2006 [Page 7] + +Internet-Draft The DHCID RR February 2006 + + + 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 + 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 obscure the client's identity information, + a one-way hash is used. And, 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. + + However, it should be noted that an attacker that has some knowledge, + such as of MAC addresses commonly used in DHCP client identification + data, may be able to discover the client's DHCP identify by using a + brute-force attack. Even without any additional knowledge, the + number of unknown bits used in computing the hash is typically only + 48 to 80. + + Administrators should be wary of permitting unsecured DNS updates to + zones, whether or not they 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 + + + + +Stapp, et al. Expires September 1, 2006 [Page 8] + +Internet-Draft The DHCID RR February 2006 + + + IANA is requested to allocate a DNS RR type number for the DHCID + record type. + + This specification defines a new number-space for the 2-octet + identifier 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 identifier + type codes are assigned through Standards Action, as defined in RFC + 2434 [5]. + + This specification defines a new number-space for the 1-octet digest + type codes associated with the DHCID RR. IANA is requested to + establish a registry of the values for this number-space. Two + initial values are assigned in Section 3.4. New DHCID RR digest type + codes are assigned through Standards Action, as defined in RFC 2434 + [5]. + + +8. Acknowledgements + + Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson, + Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie + Volz for their review and suggestions. + + +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-*)", February 2006. + + [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] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + + + + + + +Stapp, et al. Expires September 1, 2006 [Page 9] + +Internet-Draft The DHCID RR February 2006 + + +9.2. Informative References + + [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", + RFC 3548, July 2003. + + [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [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 Dynamic Host Configuration Protocol Version Four (DHCPv4)", + RFC 4361, February 2006. + + [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires September 1, 2006 [Page 10] + +Internet-Draft The DHCID RR February 2006 + + +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 + Araneus Information Systems Oy + Ulappakatu 1 + 02320 Espoo + Finland + + Email: gson@araneus.fi + + + + + + + + + + + + + + + + + + + + + + + +Stapp, et al. Expires September 1, 2006 [Page 11] + +Internet-Draft The DHCID RR February 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Stapp, et al. Expires September 1, 2006 [Page 12] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt new file mode 100644 index 0000000..7503c66 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt @@ -0,0 +1,616 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc +Updates: 4034, 4035 (if approved) J. Ihren +Expires: July 24, 2006 Autonomica AB + January 20, 2006 + + + Minimally Covering NSEC Records and DNSSEC On-line Signing + draft-ietf-dnsext-dnssec-online-signing-02 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 24, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes how to construct DNSSEC NSEC resource records + that cover a smaller range of names than called for by RFC4034. By + generating and signing these records on demand, authoritative name + servers can effectively stop the disclosure of zone contents + otherwise made possible by walking the chain of NSEC records in a + signed zone. + + + + +Weiler & Ihren Expires July 24, 2006 [Page 1] + +Internet-Draft NSEC Epsilon January 2006 + + +Changes from ietf-01 to ietf-02 + + Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG + and NSEC bits set, to be consistent with DNSSECbis -- previous text + said SHOULD. + + Made the applicability statement a little less oppressive. + +Changes from ietf-00 to ietf-01 + + Added an applicability statement, making reference to ongoing work on + NSEC3. + + Added the phrase "epsilon functions", which has been commonly used to + describe the technique and already appeared in the header of each + page, in place of "increment and decrement functions". Also added an + explanatory sentence. + + Corrected references from 4034 section 6.2 to section 6.1. + + Fixed an out-of-date reference to [-bis] and other typos. + + Replaced IANA Considerations text. + + Escaped close parentheses in examples. + + Added some more acknowledgements. + +Changes from weiler-01 to ietf-00 + + Inserted RFC numbers for 4033, 4034, and 4035. + + Specified contents of bitmap field in synthesized NSEC RR's, pointing + out that this relaxes a constraint in 4035. Added 4035 to the + Updates header. + +Changes from weiler-00 to weiler-01 + + Clarified that this updates RFC4034 by relaxing requirements on the + next name field. + + Added examples covering wildcard names. + + In the 'better functions' section, reiterated that perfect functions + aren't needed. + + Added a reference to RFC 2119. + + + + +Weiler & Ihren Expires July 24, 2006 [Page 2] + +Internet-Draft NSEC Epsilon January 2006 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 + 2. Applicability of This Technique . . . . . . . . . . . . . . . 4 + 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5 + 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 + Intellectual Property and Copyright Statements . . . . . . . . . . 11 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires July 24, 2006 [Page 3] + +Internet-Draft NSEC Epsilon January 2006 + + +1. Introduction and Terminology + + With DNSSEC [1], an NSEC record lists the next instantiated name in + its zone, proving that no names exist in the "span" between the + NSEC's owner name and the name in the "next name" field. In this + document, an NSEC record is said to "cover" the names between its + owner name and next name. + + Through repeated queries that return NSEC records, it is possible to + retrieve all of the names in the zone, a process commonly called + "walking" the zone. Some zone owners have policies forbidding zone + transfers by arbitrary clients; this side-effect of the NSEC + architecture subverts those policies. + + This document presents a way to prevent zone walking by constructing + NSEC records that cover fewer names. These records can make zone + walking take approximately as many queries as simply asking for all + possible names in a zone, making zone walking impractical. Some of + these records must be created and signed on demand, which requires + on-line private keys. Anyone contemplating use of this technique is + strongly encouraged to review the discussion of the risks of on-line + signing in Section 6. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + + +2. Applicability of This Technique + + The technique presented here may be useful to a zone owner that wants + to use DNSSEC, is concerned about exposure of its zone contents via + zone walking, and is willing to bear the costs of on-line signing. + + As discussed in Section 6, on-line signing has several security + risks, including an increased likelihood of private keys being + disclosed and an increased risk of denial of service attack. Anyone + contemplating use of this technique is strongly encouraged to review + the discussion of the risks of on-line signing in Section 6. + + Furthermore, at the time this document was published, the DNSEXT + working group was actively working on a mechanism to prevent zone + walking that does not require on-line signing (tentatively called + NSEC3). The new mechanism is likely to expose slightly more + information about the zone than this technique (e.g. the number of + instantiated names), but it may be preferable to this technique. + + + + + +Weiler & Ihren Expires July 24, 2006 [Page 4] + +Internet-Draft NSEC Epsilon January 2006 + + +3. Minimally Covering NSEC Records + + This mechanism involves changes to NSEC records for instantiated + names, which can still be generated and signed in advance, as well as + the on-demand generation and signing of new NSEC records whenever a + name must be proven not to exist. + + In the 'next name' field of instantiated names' NSEC records, rather + than list the next instantiated name in the zone, list any name that + falls lexically after the NSEC's owner name and before the next + instantiated name in the zone, according to the ordering function in + RFC4034 [2] section 6.1. This relaxes the requirement in section + 4.1.1 of RFC4034 that the 'next name' field contains the next owner + name in the zone. This change is expected to be fully compatible + with all existing DNSSEC validators. These NSEC records are returned + whenever proving something specifically about the owner name (e.g. + that no resource records of a given type appear at that name). + + Whenever an NSEC record is needed to prove the non-existence of a + name, a new NSEC record is dynamically produced and signed. The new + NSEC record has an owner name lexically before the QNAME but + lexically following any existing name and a 'next name' lexically + following the QNAME but before any existing name. + + The generated NSEC record's type bitmap MUST have the RRSIG and NSEC + bits set and SHOULD NOT have any other bits set. This relaxes the + requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at + names that did not exist before the zone was signed. + + The functions to generate the lexically following and proceeding + names need not be perfect nor consistent, but the generated NSEC + records must not cover any existing names. Furthermore, this + technique works best when the generated NSEC records cover as few + names as possible. In this document, the functions that generate the + nearby names are called 'epsilon' functions, a reference to the + mathematical convention of using the greek letter epsilon to + represent small deviations. + + An NSEC record denying the existence of a wildcard may be generated + in the same way. Since the NSEC record covering a non-existent + wildcard is likely to be used in response to many queries, + authoritative name servers using the techniques described here may + want to pregenerate or cache that record and its corresponding RRSIG. + + For example, a query for an A record at the non-instantiated name + example.com might produce the following two NSEC records, the first + denying the existence of the name example.com and the second denying + the existence of a wildcard: + + + +Weiler & Ihren Expires July 24, 2006 [Page 5] + +Internet-Draft NSEC Epsilon January 2006 + + + exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) + + \).com 3600 IN NSEC +.com ( RRSIG NSEC ) + + Before answering a query with these records, an authoritative server + must test for the existence of names between these endpoints. If the + generated NSEC would cover existing names (e.g. exampldd.com or + *bizarre.example.com), a better epsilon function may be used or the + covered name closest to the QNAME could be used as the NSEC owner + name or next name, as appropriate. If an existing name is used as + the NSEC owner name, that name's real NSEC record MUST be returned. + Using the same example, assuming an exampldd.com delegation exists, + this record might be returned from the parent: + + exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) + + Like every authoritative record in the zone, each generated NSEC + record MUST have corresponding RRSIGs generated using each algorithm + (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as + described in RFC4035 [3] section 2.2. To minimize the number of + signatures that must be generated, a zone may wish to limit the + number of algorithms in its DNSKEY RRset. + + +4. Better Epsilon Functions + + Section 6.1 of RFC4034 defines a strict ordering of DNS names. + Working backwards from that definition, it should be possible to + define epsilon functions that generate the immediately following and + preceding names, respectively. This document does not define such + functions. Instead, this section presents functions that come + reasonably close to the perfect ones. As described above, an + authoritative server should still ensure than no generated NSEC + covers any existing name. + + To increment a name, add a leading label with a single null (zero- + value) octet. + + To decrement a name, decrement the last character of the leftmost + label, then fill that label to a length of 63 octets with octets of + value 255. To decrement a null (zero-value) octet, remove the octet + -- if an empty label is left, remove the label. Defining this + function numerically: fill the left-most label to its maximum length + with zeros (numeric, not ASCII zeros) and subtract one. + + In response to a query for the non-existent name foo.example.com, + these functions produce NSEC records of: + + + + +Weiler & Ihren Expires July 24, 2006 [Page 6] + +Internet-Draft NSEC Epsilon January 2006 + + + fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) + + \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 + \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) + + The first of these NSEC RRs proves that no exact match for + foo.example.com exists, and the second proves that there is no + wildcard in example.com. + + Both of these functions are imperfect: they don't take into account + constraints on number of labels in a name nor total length of a name. + As noted in the previous section, though, this technique does not + depend on the use of perfect epsilon functions: it is sufficient to + test whether any instantiated names fall into the span covered by the + generated NSEC and, if so, substitute those instantiated owner names + for the NSEC owner name or next name, as appropriate. + + +5. IANA Considerations + + This document specifies no IANA Actions. + + +6. Security Considerations + + This approach requires on-demand generation of RRSIG records. This + creates several new vulnerabilities. + + First, on-demand signing requires that a zone's authoritative servers + have access to its private keys. Storing private keys on well-known + internet-accessible servers may make them more vulnerable to + unintended disclosure. + + Second, since generation of digital signatures tends to be + computationally demanding, the requirement for on-demand signing + makes authoritative servers vulnerable to a denial of service attack. + + Lastly, if the epsilon functions are predictable, on-demand signing + may enable a chosen-plaintext attack on a zone's private keys. Zones + using this approach should attempt to use cryptographic algorithms + that are resistant to chosen-plaintext attacks. It's worth noting + + + +Weiler & Ihren Expires July 24, 2006 [Page 7] + +Internet-Draft NSEC Epsilon January 2006 + + + that while DNSSEC has a "mandatory to implement" algorithm, that is a + requirement on resolvers and validators -- there is no requirement + that a zone be signed with any given algorithm. + + The success of using minimally covering NSEC record to prevent zone + walking depends greatly on the quality of the epsilon functions + chosen. An increment function that chooses a name obviously derived + from the next instantiated name may be easily reverse engineered, + destroying the value of this technique. An increment function that + always returns a name close to the next instantiated name is likewise + a poor choice. Good choices of epsilon functions are the ones that + produce the immediately following and preceding names, respectively, + though zone administrators may wish to use less perfect functions + that return more human-friendly names than the functions described in + Section 4 above. + + Another obvious but misguided concern is the danger from synthesized + NSEC records being replayed. It's possible for an attacker to replay + an old but still validly signed NSEC record after a new name has been + added in the span covered by that NSEC, incorrectly proving that + there is no record at that name. This danger exists with DNSSEC as + defined in [3]. The techniques described here actually decrease the + danger, since the span covered by any NSEC record is smaller than + before. Choosing better epsilon functions will further reduce this + danger. + +7. Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + +Appendix A. Acknowledgments + + Many individuals contributed to this design. They include, in + addition to the authors of this document, Olaf Kolkman, Ed Lewis, + + + +Weiler & Ihren Expires July 24, 2006 [Page 8] + +Internet-Draft NSEC Epsilon January 2006 + + + Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, + Jakob Schlyter, Bill Manning, and Joao Damas. + + In addition, the editors would like to thank Ed Lewis, Scott Rose, + and David Blacka for their careful review of the document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires July 24, 2006 [Page 9] + +Internet-Draft NSEC Epsilon January 2006 + + +Authors' Addresses + + Samuel Weiler + SPARTA, Inc + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + Email: johani@autonomica.se + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler & Ihren Expires July 24, 2006 [Page 10] + +Internet-Draft NSEC Epsilon January 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Weiler & Ihren Expires July 24, 2006 [Page 11] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt new file mode 100644 index 0000000..390420a --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt @@ -0,0 +1,392 @@ + + + +DNS Extensions working group J. Jansen +Internet-Draft NLnet Labs +Expires: July 5, 2006 January 2006 + + + Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC + draft-ietf-dnsext-dnssec-rsasha256-00 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 5, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG + resource records for use in the Domain Name System Security + Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). + + + + + + + + + +Jansen Expires July 5, 2006 [Page 1] + +Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3 + 3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3 + 4. Implementation Considerations . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 + Intellectual Property and Copyright Statements . . . . . . . . . . 7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Expires July 5, 2006 [Page 2] + +Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical distributed + database for Internet Addressing. The DNS has been extended to use + digital signatures and cryptographic keys for the verification of + data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS + Security Extensions. + + RFC4034 describes how to store DNSKEY and RRSIG resource records, and + specifies a list of cryptographic algorithms to use. This document + extends that list with the algorithm RSA/SHA-256, and specifies how + to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG + resource records. + + Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in + this document. + + +2. RSA/SHA-256 DNSKEY Resource Records + + RSA public keys for use with RSA/SHA-256 are stored in DNSKEY + resource records (RRs) with the algorithm number [TBA]. + + The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 + [6]. + + +3. RSA/SHA-256 RRSIG Resource Records + + RSA/SHA-256 signatures are stored in the DNS using RRSIG resource + records (RRs) with algorithm number [TBA]. + + The value of the signature field in the RRSIG RR is calculated as + follows. The values for the fields that precede the signature data + are specified in RFC4034 [2]. + + hash = SHA-256(data) + + signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) + + Where SHA-256 is the message digest algorithm as specified in FIPS + 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of + corresponding hexadecimal value, "e" is the private exponent of the + signing RSA key, and "n" is the public modulus of the signing key. + The FF octet MUST be repeated the maximum number of times so that the + total length of the signature equals the length of the modulus of the + signer's public key ("n"). "data" is the data of the resource record + set that is signed, as specified in RFC4034 [2]. + + + +Jansen Expires July 5, 2006 [Page 3] + +Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 + + + The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as + specified in PKCS 2.1 [4]: + + hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 + + This prefix should make the use of standard cryptographic libraries + easier. These specifications are taken directly from PKCS #1 v2.1 + section 9.2 [4]. + + +4. Implementation Considerations + + DNSSEC aware implementations MUST be able to support RRSIG resource + records with the RSA/SHA-256 algorithm. + + If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are + available for a certain rrset, with a secure path to their keys, the + validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256 + signature does not verify the data, and the RSA/SHA-1 does, the + validator SHOULD mark the data with the security status from the RSA/ + SHA-256 signature. + + +5. IANA Considerations + + IANA has not yet assigned an algorithm number for RSA/SHA-256. + + The algorithm list from RFC4034 Appendix A.1 [2] is extended with the + following entry: + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- ----------- ----------- -------- ---------- --------- + [tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY + + +6. Security Considerations + + Recently, weaknesses have been discovered in the SHA-1 hashing + algorithm. It is therefore strongly encouraged to deploy SHA-256 + where SHA-1 is used now, as soon as the DNS software supports it. + + SHA-256 is considered sufficiently strong for the immediate future, + but predictions about future development in cryptography and + cryptanalysis are beyond the scope of this document. + + + + + + +Jansen Expires July 5, 2006 [Page 4] + +Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 + + +7. Acknowledgments + + This document is a minor extension to RFC4034 [2]. Also, we try to + follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt + [8] for consistency. The authors of and contributors to these + documents are gratefully acknowledged for their hard work. + + The following people provided additional feedback and text: Jaap + Akkerhuis, Miek Gieben and Wouter Wijngaards. + + +8. References + +8.1. Normative References + + [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards + (PKCS) #1: RSA Cryptography Specifications Version 2.1", + RFC 3447, February 2003. + + [5] National Institute of Standards and Technology, "Secure Hash + Standard", FIPS PUB 180-2, August 2002. + + [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + +8.2. Informative References + + [7] Schneier, B., "Applied Cryptography Second Edition: protocols, + algorithms, and source code in C", Wiley and Sons , ISBN 0-471- + 11709-9, 1996. + + [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) + Resource Records (RRs)", Work in Progress Feb 2006. + + + + + + +Jansen Expires July 5, 2006 [Page 5] + +Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 + + +Author's Address + + Jelte Jansen + NLnet Labs + Kruislaan 419 + Amsterdam 1098VA + NL + + Email: jelte@NLnetLabs.nl + URI: http://www.nlnetlabs.nl/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Expires July 5, 2006 [Page 6] + +Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Jansen Expires July 5, 2006 [Page 7] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt new file mode 100644 index 0000000..2460cb6 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt @@ -0,0 +1,504 @@ + + + +Network Working Group W. Hardaker +Internet-Draft Sparta +Expires: August 25, 2006 February 21, 2006 + + + Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) + draft-ietf-dnsext-ds-sha256-05.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 25, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies how to use the SHA-256 digest type in DNS + Delegation Signer (DS) Resource Records (RRs). DS records, when + stored in a parent zone, point to key signing DNSKEY key(s) in a + child zone. + + + + + + + + +Hardaker Expires August 25, 2006 [Page 1] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Implementing the SHA-256 algorithm for DS record support . . . 3 + 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 + 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 + 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4 + 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 + 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5 + 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Expires August 25, 2006 [Page 2] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + +1. Introduction + + The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent + zones to distribute a cryptographic digest of a child's Key Signing + Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the + parent zone's private zone data signing keys for each algorithm in + use by the parent. Each signature is published in an RRSIG resource + record, owned by the same domain as the DS RRset and with a type + covered of DS. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + +2. Implementing the SHA-256 algorithm for DS record support + + This document specifies that the digest type code [XXX: To be + assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] + [SHA256CODE] for use within DS records. The results of the digest + algorithm MUST NOT be truncated and the entire 32 byte digest result + is to be published in the DS record. + +2.1. DS record field values + + Using the SHA-256 digest algorithm within a DS record will make use + of the following DS-record fields: + + Digest type: [XXX: To be assigned by IANA; likely 2] + + Digest: A SHA-256 bit digest value calculated by using the following + formula ("|" denotes concatenation). The resulting value is not + truncated and the entire 32 byte result is to used in the + resulting DS record and related calculations. + + digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) + + where DNSKEY RDATA is defined by [RFC4034] as: + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key + + The Key Tag field and Algorithm fields remain unchanged by this + document and are specified in the [RFC4034] specification. + +2.2. DS Record with SHA-256 Wire Format + + The resulting on-the-wire format for the resulting DS record will be + [XXX: IANA assignment should replace the 2 below]: + + + +Hardaker Expires August 25, 2006 [Page 3] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | DigestType=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest (length for SHA-256 is 32 bytes) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + +2.3. Example DS Record Using SHA-256 + + The following is an example DNSKEY and matching DS record. This + DNSKEY record comes from the example DNSKEY/DS records found in + section 5.4 of [RFC4034]. + + The DNSKEY record: + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + The resulting DS record covering the above DNSKEY record using a SHA- + 256 digest: [RFC Editor: please replace XXX with the assigned digest + type (likely 2):] + + dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C + CEB1E3E0614B93C4F9E99B83 + 83F6A1E4469DA50A ) + + +3. Implementation Requirements + + Implementations MUST support the use of the SHA-256 algorithm in DS + RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 + digests if DS RRs with SHA-256 digests are present in the DS RRset. + + +4. Deployment Considerations + + If a validator does not support the SHA-256 digest type and no other + DS RR exists in a zone's DS RRset with a supported digest type, then + + + +Hardaker Expires August 25, 2006 [Page 4] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + + the validator has no supported authentication path leading from the + parent to the child. The resolver should treat this case as it would + the case of an authenticated NSEC RRset proving that no DS RRset + exists, as described in [RFC4035], section 5.2. + + Because zone administrators can not control the deployment speed of + support for SHA-256 in validators that may be referencing any of + their zones, zone operators should consider deploying both SHA-1 and + SHA-256 based DS records. This should be done for every DNSKEY for + which DS records are being generated. Whether to make use of both + digest types and for how long is a policy decision that extends + beyond the scope of this document. + + +5. IANA Considerations + + Only one IANA action is required by this document: + + The Digest Type to be used for supporting SHA-256 within DS records + needs to be assigned by IANA. This document requests that the Digest + Type value of 2 be assigned to the SHA-256 digest algorithm. + + At the time of this writing, the current digest types assigned for + use in DS records are as follows: + + VALUE Digest Type Status + 0 Reserved - + 1 SHA-1 MANDATORY + 2 SHA-256 MANDATORY + 3-255 Unassigned - + + +6. Security Considerations + +6.1. Potential Digest Type Downgrade Attacks + + A downgrade attack from a stronger digest type to a weaker one is + possible if all of the following are true: + + o A zone includes multiple DS records for a given child's DNSKEY, + each of which use a different digest type. + + o A validator accepts a weaker digest even if a stronger one is + present but invalid. + + For example, if the following conditions are all true: + + + + + +Hardaker Expires August 25, 2006 [Page 5] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + + o Both SHA-1 and SHA-256 based digests are published in DS records + within a parent zone for a given child zone's DNSKEY. + + o The DS record with the SHA-1 digest matches the digest computed + using the child zone's DNSKEY. + + o The DS record with the SHA-256 digest fails to match the digest + computed using the child zone's DNSKEY. + + Then if the validator accepts the above situation as secure then this + can be used as a downgrade attack since the stronger SHA-256 digest + is ignored. + +6.2. SHA-1 vs SHA-256 Considerations for DS Records + + Users of DNSSEC are encouraged to deploy SHA-256 as soon as software + implementations allow for it. SHA-256 is widely believed to be more + resilient to attack than SHA-1, and confidence in SHA-1's strength is + being eroded by recently-announced attacks. Regardless of whether or + not the attacks on SHA-1 will affect DNSSEC, it is believed (at the + time of this writing) that SHA-256 is the better choice for use in DS + records. + + At the time of this publication, the SHA-256 digest algorithm is + considered sufficiently strong for the immediate future. It is also + considered sufficient for use in DNSSEC DS RRs for the immediate + future. However, future published attacks may weaken the usability + of this algorithm within the DS RRs. It is beyond the scope of this + document to speculate extensively on the cryptographic strength of + the SHA-256 digest algorithm. + + Likewise, it is also beyond the scope of this document to specify + whether or for how long SHA-1 based DS records should be + simultaneously published alongside SHA-256 based DS records. + + +7. Acknowledgments + + This document is a minor extension to the existing DNSSEC documents + and those authors are gratefully appreciated for the hard work that + went into the base documents. + + The following people contributed to portions of this document in some + fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, + Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam + Weiler. + + + + + +Hardaker Expires August 25, 2006 [Page 6] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [SHA256] National Institute of Standards and Technology, "Secure + Hash Algorithm. NIST FIPS 180-2", August 2002. + +8.2. Informative References + + [SHA256CODE] + Eastlake, D., "US Secure Hash Algorithms (SHA)", + June 2005. + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Expires August 25, 2006 [Page 7] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + +Author's Address + + Wes Hardaker + Sparta + P.O. Box 382 + Davis, CA 95617 + US + + Email: hardaker@tislabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Expires August 25, 2006 [Page 8] + +Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Hardaker Expires August 25, 2006 [Page 9] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt new file mode 100644 index 0000000..8c6c5b1 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt @@ -0,0 +1,2352 @@ + + + +Network Working Group B. Laurie +Internet-Draft G. Sisson +Expires: August 5, 2006 R. Arends + Nominet + February 2006 + + + DNSSEC Hash Authenticated Denial of Existence + draft-ietf-dnsext-nsec3-04 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 5, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The DNS Security Extensions introduces the NSEC resource record for + authenticated denial of existence. This document introduces a new + resource record as an alternative to NSEC that provides measures + against zone enumeration and allows for gradual expansion of + delegation-centric zones. + + + + + +Laurie, et al. Expires August 5, 2006 [Page 1] + +Internet-Draft nsec3 February 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5 + 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 + 3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6 + 3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6 + 3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7 + 3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8 + 3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8 + 3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8 + 3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9 + 3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9 + 3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10 + 4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11 + 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11 + 6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11 + 7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12 + 8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13 + 8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13 + 8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16 + 8.4.1. Avoiding Hash Collisions during generation . . . . . . 16 + 8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16 + 8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17 + 8.4.4. Server Response to a Run-time Collision . . . . . . . 17 + 8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18 + 9. Performance Considerations . . . . . . . . . . . . . . . . . . 18 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . + Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22 + Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 27 + B.1. answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + B.1.1. Authenticating the Example DNSKEY RRset . . . . . . . 29 + B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30 + B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . . 32 + B.3.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 33 + B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . . 34 + B.5. Referral to Unsigned Zone using the Opt-In Flag . . . . . 35 + B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36 + + + +Laurie, et al. Expires August 5, 2006 [Page 2] + +Internet-Draft nsec3 February 2006 + + + B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38 + B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . . 39 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 + Intellectual Property and Copyright Statements . . . . . . . . . . 42 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 3] + +Internet-Draft nsec3 February 2006 + + +1. Introduction + +1.1. Rationale + + The DNS Security Extensions included the NSEC RR to provide + authenticated denial of existence. Though the NSEC RR meets the + requirements for authenticated denial of existence, it introduced a + side-effect in that the contents of a zone can be enumerated. This + property introduces undesired policy issues. + + An enumerated zone can be used either directly as a source of + probable e-mail addresses for spam, or indirectly as a key for + multiple WHOIS queries to reveal registrant data which many + registries may be under strict legal obligations to protect. Many + registries therefore prohibit copying of their zone file; however the + use of NSEC RRs renders these policies unenforceable. + + A second problem was the requirement that the existence of all record + types in a zone - including unsigned delegation points - must be + accounted for, despite the fact that unsigned delegation point + records are not signed. This requirement has a side-effect that the + overhead of signed zones is not related to the increase in security + of subzones. This requirement does not allow the zones' size to grow + in relation to the growth of signed subzones. + + In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been + proposed as a measure against these side effects but at the time were + regarded as secondary over the need to have a stable DNSSEC + specification. With (draft-vixie-dnssec-ter) [14] a graceful + transition path to future enhancements is introduced, while current + DNSSEC deployment can continue. This document presents the NSEC3 + Resource Record which mitigates these issues with the NSEC RR. + + The reader is assumed to be familiar with the basic DNS and DNSSEC + concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC + 4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136 + [6], RFC2181 [7] and RFC2308 [8]. + +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 [9]. + +1.3. Terminology + + The practice of discovering the contents of a zone, i.e. enumerating + the domains within a zone, is known as "zone enumeration". Zone + + + +Laurie, et al. Expires August 5, 2006 [Page 4] + +Internet-Draft nsec3 February 2006 + + + enumeration was not practical prior to the introduction of DNSSEC. + + In this document the term "original ownername" refers to a standard + ownername. Because this proposal uses the result of a hash function + over the original (unmodified) ownername, this result is referred to + as "hashed ownername". + + "Hash order" means the order in which hashed ownernames are arranged + according to their numerical value, treating the leftmost (lowest + numbered) octet as the most significant octet. Note that this is the + same as the canonical ordering specified in RFC 4034 [4]. + + An "empty non-terminal" is a domain name that owns no resource + records but has subdomains that do. + + The "closest encloser" of a (nonexistent) domain name is the longest + domain name, including empty non-terminals, that matches the + rightmost part of the nonexistent domain name. + + "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as + specified in RFC 3548bis [15]. + + +2. NSEC versus NSEC3 + + This document does NOT obsolete the NSEC record, but gives an + alternative for authenticated denial of existence. NSEC and NSEC3 + RRs can not co-exist in a zone. See draft-vixie-dnssec-ter [14] for + a signaling mechanism to allow for graceful transition towards NSEC3. + + +3. The NSEC3 Resource Record + + The NSEC3 RR provides Authenticated Denial of Existence for DNS + Resource Record Sets. + + The NSEC3 Resource Record (RR) lists RR types present at the NSEC3 + RR's original ownername. It includes the next hashed ownername in + the hash order of the zone. The complete set of NSEC3 RRs in a zone + indicates which RRsets exist for the original ownername of the RRset + and form a chain of hashed ownernames in the zone. This information + is used to provide authenticated denial of existence for DNS data, as + described in RFC 4035 [5]. To provide protection against zone + enumeration, the ownernames used in the NSEC3 RR are cryptographic + hashes of the original ownername prepended to the name of the zone. + The NSEC3 RR indicates which hash function is used to construct the + hash, which salt is used, and how many iterations of the hash + function are performed over the original ownername. The hashing + + + +Laurie, et al. Expires August 5, 2006 [Page 5] + +Internet-Draft nsec3 February 2006 + + + technique is described fully in Section 5. + + Hashed ownernames of unsigned delegations may be excluded from the + chain. An NSEC3 record which span covers the hash of an unsigned + delegation's ownername is referred to as an Opt-In NSEC3 record and + is indicated by the presence of a flag. + + The ownername for the NSEC3 RR is the base32 encoding of the hashed + ownername prepended to the name of the zone.. + + The type value for the NSEC3 RR is XX. + + The NSEC3 RR RDATA format is class independent and is described + below. + + The class MUST be the same as the original ownername's class. + + The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [8]. + +3.1. NSEC3 RDATA Wire Format + + The RDATA of the NSEC3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hash Function |O| Iterations | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Salt Length | Salt / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Hashed Ownername / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + "O" is the Opt-In Flag field. + +3.1.1. The Hash Function Field + + The Hash Function field identifies the cryptographic hash function + used to construct the hash-value. + + The values are as defined for the DS record (see RFC 3658 [10]). + + On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash + function value. + + + + +Laurie, et al. Expires August 5, 2006 [Page 6] + +Internet-Draft nsec3 February 2006 + + +3.1.2. The Opt-In Flag Field + + The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned + delegations. + + In DNSSEC, NS RRsets at delegation points are not signed, and may be + accompanied by a DS record. The security status of the subzone is + determined by the presence or absence of the DS RRset, + cryptographically proven by the NSEC record or the signed DS RRset. + The presence of the Opt-In flag expands this definition by allowing + insecure delegations to exist within an otherwise signed zone without + the corresponding NSEC3 record at the delegation's (hashed) owner + name. These delegations are proven insecure by using a covering + NSEC3 record. + + Resolvers must be able to distinguish between NSEC3 records and + Opt-In NSEC3 records. This is accomplished by setting the Opt-In + flag of the NSEC3 records that cover (or potentially cover) insecure + delegation nodes. + + An Opt-In NSEC3 record does not assert the existence or non-existence + of the insecure delegations that it covers. This allows for the + addition or removal of these delegations without recalculating or + resigning records in the NSEC3 chain. However, Opt-In NSEC3 records + do assert the (non)existence of other, authoritative RRsets. + + An Opt-In NSEC3 record MAY have the same original owner name as an + insecure delegation. In this case, the delegation is proven insecure + by the lack of a DS bit in type map and the signed NSEC3 record does + assert the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and + non-Opt-In NSEC3 records. If an NSEC3 record is not Opt-In, there + MUST NOT be any hashed ownernames of insecure delegations (nor any + other records) between it and the RRsets indicated by the 'Next + Hashed Ownername' in the NSEC3 RDATA. If it is Opt-In, there MUST + only be hashed ownernames of insecure delegations between it and the + next node indicated by the 'Next Hashed Ownername' in the NSEC3 + RDATA. + + In summary, + o An Opt-In NSEC3 type is identified by an Opt-In Flag field value + of 1. + o A non Opt-In NSEC3 type is identified by an Opt-In Flag field + value of 0. + and, + + + + + +Laurie, et al. Expires August 5, 2006 [Page 7] + +Internet-Draft nsec3 February 2006 + + + o An Opt-In NSEC3 record does not assert the non-existence of a hash + ownername between its ownername and next hashed ownername, + although it does assert that any hashed name in this span MUST be + of an insecure delegation. + o An Opt-In NSEC3 record does assert the (non)existence of RRsets + with the same hashed owner name. + +3.1.3. The Iterations Field + + The Iterations field defines the number of times the hash has been + iterated. More iterations results in greater resiliency of the hash + value against dictionary attacks, but at a higher cost for both the + server and resolver. See Section 5 for details of this field's use. + + Iterations make an attack more costly by making the hash computation + more computationally intensive, e.g. by iterating the hash function a + number of times. + + When generating a few hashes this performance loss will not be a + problem, as a validator can handle a delay of a few milliseconds. + But when doing a dictionary attack it will also multiply the attack + workload by a factor, which is a problem for the attacker. + +3.1.4. The Salt Length Field + + The salt length field defines the length of the salt in octets. + +3.1.5. The Salt Field + + The Salt field is not present when the Salt Length Field has a value + of 0. + + The Salt field is appended to the original ownername before hashing + in order to defend against precalculated dictionary attacks. See + Section 5 for details on how the salt is used. + + Salt is used to make dictionary attacks using precomputation more + costly. A dictionary can only be computed after the attacker has the + salt, hence a new salt means that the dictionary has to be + regenerated with the new salt. + + There MUST be a complete set of NSEC3 records covering the entire + zone that use the same salt value. The requirement exists so that, + given any qname within a zone, at least one covering NSEC3 RRset may + be found. While it may be theoretically possible to produce a set of + NSEC3s that use different salts that cover the entire zone, it is + computationally infeasible to generate such a set. See Section 8.2 + for further discussion. + + + +Laurie, et al. Expires August 5, 2006 [Page 8] + +Internet-Draft nsec3 February 2006 + + + The salt value SHOULD be changed from time to time - this is to + prevent the use of a precomputed dictionary to reduce the cost of + enumeration. + +3.1.6. The Next Hashed Ownername Field + + The Next Hashed Ownername field contains the next hashed ownername in + hash order. That is, given the set of all hashed owernames, the Next + Hashed Ownername contains the hash value that immediately follows the + owner hash value for the given NSEC3 record. The value of the Next + Hashed Ownername Field in the last NSEC3 record in the zone is the + same as the ownername of the first NSEC3 RR in the zone in hash + order. + + Hashed ownernames of glue RRsets MUST NOT be listed in the Next + Hashed Ownername unless at least one authoritative RRset exists at + the same ownername. Hashed ownernames of delegation NS RRsets MUST + be listed if the Opt-In bit is clear. + + Note that the Next Hashed Ownername field is not encoded, unlike the + NSEC3 RR's ownername. It is the unmodified binary hash value. It + does not include the name of the containing zone. + + The length of this field is the length of the hash value produced by + the hash function selected by the Hash Function field. + +3.1.7. The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC3 RR's original ownername. + + The Type bits for the NSEC3 RR and RRSIG RR MUST be set during + generation, and MUST be ignored during processing. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that + has at least one active RR type is encoded using a single octet + window number (from 0 to 255), a single octet bitmap length (from 1 + to 32) indicating the number of octets used for the window block's + bitmap, and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC3 RR RDATA in increasing numerical + order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + + + +Laurie, et al. Expires August 5, 2006 [Page 9] + +Internet-Draft nsec3 February 2006 + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC3 + RR's ownername. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC3 RR's ownername. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11] + (section 3.1) or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in + zone data. If encountered, they must be ignored upon reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC3 RR's actual ownername. Trailing zero octets not specified MUST + be interpreted as zero octets. + +3.2. The NSEC3 RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Opt-In Flag Field is represented as an unsigned decimal integer. + The value is either 0 or 1. + + The Hash field is presented as a mnemonic of the hash or as an + unsigned decimal integer. The value has a maximum of 127. + + The Iterations field is presented as an unsigned decimal integer. + + The Salt Length field is not presented. + + The Salt field is represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is not allowed within the sequence. + The Salt Field is represented as "-" (without the quotes) when the + Salt Length field has value 0. + + The Next Hashed Ownername field is represented as a sequence of case- + insensitive base32 digits, without whitespace. + + The Type Bit Maps Field is represented as a sequence of RR type + + + +Laurie, et al. Expires August 5, 2006 [Page 10] + +Internet-Draft nsec3 February 2006 + + + mnemonics. When the mnemonic is not known, the TYPE representation + as described in RFC 3597 [12] (section 5) MUST be used. + + +4. Creating Additional NSEC3 RRs for Empty Non-Terminals + + In order to prove the non-existence of a record that might be covered + by a wildcard, it is necessary to prove the existence of its closest + encloser. A closest encloser might be an empty non-terminal. + + Additional NSEC3 RRs are generated for empty non-terminals. These + additional NSEC3 RRs are identical in format to NSEC3 RRs that cover + existing RRs in the zone except that their type-maps only indicated + the existence of an NSEC3 RRset and an RRSIG RRset. + + This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs + not appear at names that did not exist before the zone was signed. + [Comment.1] + + +5. Calculation of the Hash + + Define H(x) to be the hash of x using the hash function selected by + the NSEC3 record and || to indicate concatenation. Then define: + + IH(salt,x,0)=H(x || salt) + + IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 + + Then the calculated hash of an ownername is + IH(salt,ownername,iterations-1), where the ownername is the canonical + form. + + The canonical form of the ownername is the wire format of the + ownername where: + 1. The ownername is fully expanded (no DNS name compression) and + fully qualified; + 2. All uppercase US-ASCII letters are replaced by the corresponding + lowercase US-ASCII letters; + 3. If the ownername is a wildcard name, the ownername is in its + original unexpanded form, including the "*" label (no wildcard + substitution); + This form is as defined in section 6.2 of RFC 4034 ([4]). + + +6. Including NSEC3 RRs in a Zone + + Each ownername within the zone that owns authoritative RRsets MUST + + + +Laurie, et al. Expires August 5, 2006 [Page 11] + +Internet-Draft nsec3 February 2006 + + + have a corresponding NSEC3 RR. Ownernames that correspond to + unsigned delegations MAY have a corresponding NSEC3 RR, however, if + there is not, there MUST be a covering NSEC3 RR with the Opt-In flag + set to 1. Other non-authoritative RRs are not included in the set of + NSEC3 RRs. + + Each empty non-terminal MUST have an NSEC3 record. + + The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + The type bitmap of every NSEC3 resource record in a signed zone MUST + indicate the presence of both the NSEC3 RR type itself and its + corresponding RRSIG RR type. + + The following steps describe the proper construction of NSEC3 + records. [Comment.2] + 1. For each unique original ownername in the zone, add an NSEC3 + RRset. If Opt-In is being used, ownernames of unsigned + delegations may be excluded, but must be considered for empty- + non-terminals. The ownername of the NSEC3 RR is the hashed + equivalent of the original owner name, prepended to the zone + name. The Next Hashed Ownername field is left blank for the + moment. If Opt-In is being used, set the Opt-In bit to one. + 2. For each RRset at the original owner name, set the corresponding + bit in the type bit map. + 3. If the difference in number of labels between the apex and the + original ownername is greater then 1, additional NSEC3s need to + be added for every empty non-terminal between the apex and the + original ownername. This process may generate NSEC3 RRs with + duplicate hashed ownernames. + 4. Sort the set of NSEC3 RRs into hash order. Hash order is the + ascending numerical order of the non-encoded hash values. + 5. Combine NSEC3 RRs with identical hashed ownernames by replacing + with a single NSEC3 RR with the type map consisting of the union + of the types represented by the set of NSEC3 RRs. + 6. In each NSEC3 RR, insert the Next Hashed Ownername by using the + value of the next NSEC3 RR in hash order. The Next Hashed + Ownername of the last NSEC3 in the zone contains the value of the + hashed ownername of the first NSEC3 in the hash order. + + +7. Responding to NSEC3 Queries + + Since NSEC3 ownernames are not represented in the NSEC3 chain like + other zone ownernames, direct queries for NSEC3 ownernames present a + special case. + + + + +Laurie, et al. Expires August 5, 2006 [Page 12] + +Internet-Draft nsec3 February 2006 + + + The special case arises when the following are all true: + o The QNAME equals an existing NSEC3 ownername, and + o There are no other record types that exist at QNAME, and + o The QTYPE does not equal NSEC3. + These conditions describe a particular case: the answer should be a + NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to + include in the authority section. + + However, the NSEC3 RRset with ownername equal to QNAME is able to + prove its own existence. Thus, when answering this query, the + authoritative server MUST include the NSEC3 RRset whose ownername + equals QNAME. This RRset proves that QNAME is an existing name with + types NSEC3 and RRSIG. The authoritative server MUST also include + the NSEC3 RRset that covers the hash of QNAME. This RRset proves + that no other types exist. + + When validating a NOERROR/NODATA response, validators MUST check for + a NSEC3 RRset with ownername equals to QNAME, and MUST accept that + (validated) NSEC3 RRset as proof that QNAME exists. The validator + MUST also check for an NSEC3 RRset that covers the hash of QNAME as + proof that QTYPE doesn't exist. + + Other cases where the QNAME equals an existing NSEC3 ownername may be + answered normally. + + +8. Special Considerations + + The following paragraphs clarify specific behaviour explain special + considerations for implementations. + +8.1. Proving Nonexistence + + If a wildcard resource record appears in a zone, its asterisk label + is treated as a literal symbol and is treated in the same way as any + other ownername for purposes of generating NSEC3 RRs. RFC 4035 [5] + describes the impact of wildcards on authenticated denial of + existence. + + In order to prove there exist no RRs for a domain, as well as no + source of synthesis, an RR must be shown for the closest encloser, + and non-existence must be shown for all closer labels and for the + wildcard at the closest encloser. + + This can be done as follows. If the QNAME in the query is + omega.alfa.beta.example, and the closest encloser is beta.example + (the nearest ancestor to omega.alfa.beta.example), then the server + should return an NSEC3 that demonstrates the nonexistence of + + + +Laurie, et al. Expires August 5, 2006 [Page 13] + +Internet-Draft nsec3 February 2006 + + + alfa.beta.example, an NSEC3 that demonstrates the nonexistence of + *.beta.example, and an NSEC3 that demonstrates the existence of + beta.example. This takes between one and three NSEC3 records, since + a single record can, by chance, prove more than one of these facts. + + When a verifier checks this response, then the existence of + beta.example together with the non-existence of alfa.beta.example + proves that the closest encloser is indeed beta.example. The non- + existence of *.beta.example shows that there is no wildcard at the + closest encloser, and so no source of synthesis for + omega.alfa.beta.example. These two facts are sufficient to satisfy + the resolver that the QNAME cannot be resolved. + + In practice, since the NSEC3 owner and next names are hashed, if the + server responds with an NSEC3 for beta.example, the resolver will + have to try successively longer names, starting with example, moving + to beta.example, alfa.beta.example, and so on, until one of them + hashes to a value that matches the interval (but not the ownername + nor next owner name) of one of the returned NSEC3s (this name will be + alfa.beta.example). Once it has done this, it knows the closest + encloser (i.e. beta.example), and can then easily check the other two + required proofs. + + Note that it is not possible for one of the shorter names tried by + the resolver to be denied by one of the returned NSEC3s, since, by + definition, all these names exist and so cannot appear within the + range covered by an NSEC3. Note, however, that the first name that + the resolver tries MUST be the apex of the zone, since names above + the apex could be denied by one of the returned NSEC3s. + +8.2. Salting + + Augmenting original ownernames with salt before hashing increases the + cost of a dictionary of pre-generated hash-values. For every bit of + salt, the cost of a precomputed dictionary doubles (because there + must be an entry for each word combined with each possible salt + value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of + salt, multiplying the cost by 2^2040. This means that an attacker + must, in practice, recompute the dictionary each time the salt is + changed. + + There MUST be at least one complete set of NSEC3s for the zone using + the same salt value. + + The salt SHOULD be changed periodically to prevent precomputation + using a single salt. It is RECOMMENDED that the salt be changed for + every resigning. + + + + +Laurie, et al. Expires August 5, 2006 [Page 14] + +Internet-Draft nsec3 February 2006 + + + Note that this could cause a resolver to see records with different + salt values for the same zone. This is harmless, since each record + stands alone (that is, it denies the set of ownernames whose hashes, + using the salt in the NSEC3 record, fall between the two hashes in + the NSEC3 record) - it is only the server that needs a complete set + of NSEC3 records with the same salt in order to be able to answer + every possible query. + + There is no prohibition with having NSEC3 with different salts within + the same zone. However, in order for authoritative servers to be + able to consistently find covering NSEC3 RRs, the authoritative + server MUST choose a single set of parameters (algorithm, salt, and + iterations) to use when selecting NSEC3s. In the absence of any + other metadata, the server does this by using the parameters from the + zone apex NSEC3, recognizable by the presence of the SOA bit in the + type map. If there is more than one NSEC3 record that meets this + description, then the server may arbitrarily choose one. Because of + this, if there is a zone apex NSEC3 RR within a zone, it MUST be part + of a complete NSEC3 set. Conversely, if there exists an incomplete + set of NSEC3 RRs using the same parameters within a zone, there MUST + NOT be an NSEC3 RR using those parameters with the SOA bit set. + +8.3. Iterations + + Setting the number of iterations used allows the zone owner to choose + the cost of computing a hash, and so the cost of generating a + dictionary. Note that this is distinct from the effect of salt, + which prevents the use of a single precomputed dictionary for all + time. + + Obviously the number of iterations also affects the zone owner's cost + of signing the zone as well as the verifiers cost of verifying the + zone. We therefore impose an upper limit on the number of + iterations. We base this on the number of iterations that + approximately doubles the cost of signing the zone. + + A zone owner MUST NOT use a value higher than shown in the table + below for iterations. A resolver MAY treat a response with a higher + value as bogus. + + +--------------+------------+ + | RSA Key Size | Iterations | + +--------------+------------+ + | 1024 | 3,000 | + | 2048 | 20,000 | + | 4096 | 150,000 | + +--------------+------------+ + + + + +Laurie, et al. Expires August 5, 2006 [Page 15] + +Internet-Draft nsec3 February 2006 + + + +--------------+------------+ + | DSA Key Size | Iterations | + +--------------+------------+ + | 1024 | 1,500 | + | 2048 | 5,000 | + +--------------+------------+ + + This table is based on 150,000 SHA-1's per second, 50 RSA signs per + second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1 + sign per second for 4096 bit keys, 100 DSA signs per second for 1024 + bit keys and 30 signs per second for 2048 bit keys. + + Note that since RSA verifications are 10-100 times faster than + signatures (depending on key size), in the case of RSA the legal + values of iterations can substantially increase the cost of + verification. + +8.4. Hash Collision + + Hash collisions occur when different messages have the same hash + value. The expected number of domain names needed to give a 1 in 2 + chance of a single collision is about 2^(n/2) for a hash of length n + bits (i.e. 2^80 for SHA-1). Though this probability is extremely + low, the following paragraphs deal with avoiding collisions and + assessing possible damage in the event of an attack using hash + collisions. + +8.4.1. Avoiding Hash Collisions during generation + + During generation of NSEC3 RRs, hash values are supposedly unique. + In the (academic) case of a collision occurring, an alternative salt + MUST be chosen and all hash values MUST be regenerated. + +8.4.2. Second Preimage Requirement Analysis + + A cryptographic hash function has a second-preimage resistance + property. The second-preimage resistance property means that it is + computationally infeasible to find another message with the same hash + value as a given message, i.e. given preimage X, to find a second + preimage X' != X such that hash(X) = hash(X'). The work factor for + finding a second preimage is of the order of 2^160 for SHA-1. To + mount an attack using an existing NSEC3 RR, an adversary needs to + find a second preimage. + + Assuming an adversary is capable of mounting such an extreme attack, + the actual damage is that a response message can be generated which + claims that a certain QNAME (i.e. the second pre-image) does exist, + while in reality QNAME does not exist (a false positive), which will + + + +Laurie, et al. Expires August 5, 2006 [Page 16] + +Internet-Draft nsec3 February 2006 + + + either cause a security aware resolver to re-query for the non- + existent name, or to fail the initial query. Note that the adversary + can't mount this attack on an existing name but only on a name that + the adversary can't choose and does not yet exist. + +8.4.3. Possible Hash Value Truncation Method + + The previous sections outlined the low probability and low impact of + a second-preimage attack. When impact and probability are low, while + space in a DNS message is costly, truncation is tempting. Truncation + might be considered to allow for shorter ownernames and rdata for + hashed labels. In general, if a cryptographic hash is truncated to n + bits, then the expected number of domains required to give a 1 in 2 + probability of a single collision is approximately 2^(n/2) and the + work factor to produce a second preimage is 2^n. + + An extreme hash value truncation would be truncating to the shortest + possible unique label value. This would be unwise, since the work + factor to produce second preimages would then approximate the size of + the zone (sketch of proof: if the zone has k entries, then the length + of the names when truncated down to uniqueness should be proportional + to log_2(k). Since the work factor to produce a second pre-image is + 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where + C is some constant), i.e. C'k - a work factor of k). + + Though the mentioned truncation can be maximized to a certain + extreme, the probability of collision increases exponentially for + every truncated bit. Given the low impact of hash value collisions + and limited space in DNS messages, the balance between truncation + profit and collision damage may be determined by local policy. Of + course, the size of the corresponding RRSIG RR is not reduced, so + truncation is of limited benefit. + + Truncation could be signaled simply by reducing the length of the + first label in the ownername. Note that there would have to be a + corresponding reduction in the length of the Next Hashed Ownername + field. + +8.4.4. Server Response to a Run-time Collision + + In the astronomically unlikely event that a server is unable to prove + nonexistence because the hash of the name that does not exist + collides with a name that does exist, the server is obviously broken, + and should, therefore, return a response with an RCODE of 2 (server + failure). + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 17] + +Internet-Draft nsec3 February 2006 + + +8.4.5. Parameters that Cover the Zone + + Secondary servers (and perhaps other entities) need to reliably + determine which NSEC3 parameters (that is, hash, salt and iterations) + are present at every hashed ownername, in order to be able to choose + an appropriate set of NSEC3 records for negative responses. This is + indicated by the parameters at the apex: any set of parameters that + is used in an NSEC3 record whose original ownername is the apex of + the zone MUST be present throughout the zone. + + A method to determine which NSEC3 in a complete chain corresponds to + the apex is to look for a NSEC3 RRset which has the SOA bit set in + the RDATA bit type maps field. + + +9. Performance Considerations + + Iterated hashes impose a performance penalty on both authoritative + servers and resolvers. Therefore, the number of iterations should be + carefully chosen. In particular it should be noted that a high value + for iterations gives an attacker a very good denial of service + attack, since the attacker need not bother to verify the results of + their queries, and hence has no performance penalty of his own. + + On the other hand, nameservers with low query rates and limited + bandwidth are already subject to a bandwidth based denial of service + attack, since responses are typically an order of magnitude larger + than queries, and hence these servers may choose a high value of + iterations in order to increase the difficulty of offline attempts to + enumerate their namespace without significantly increasing their + vulnerability to denial of service attacks. + + +10. IANA Considerations + + IANA needs to allocate a RR type code for NSEC3 from the standard RR + type space (type XXX requested). IANA needs to open a new registry + for the NSEC3 Hash Functions. The range for this registry is 0-127. + Defined types are: + + 0 is reserved. + 1 is SHA-1 ([13]). + 127 is experimental. + + +11. Security Considerations + + The NSEC3 records are still susceptible to dictionary attacks (i.e. + + + +Laurie, et al. Expires August 5, 2006 [Page 18] + +Internet-Draft nsec3 February 2006 + + + the attacker retrieves all the NSEC3 records, then calculates the + hashes of all likely domain names, comparing against the hashes found + in the NSEC3 records, and thus enumerating the zone). These are + substantially more expensive than enumerating the original NSEC + records would have been, and in any case, such an attack could also + be used directly against the name server itself by performing queries + for all likely names, though this would obviously be more detectable. + The expense of this off-line attack can be chosen by setting the + number of iterations in the NSEC3 RR. + + Domains are also susceptible to a precalculated dictionary attack - + that is, a list of hashes for all likely names is computed once, then + NSEC3 is scanned periodically and compared against the precomputed + hashes. This attack is prevented by changing the salt on a regular + basis. + + Walking the NSEC3 RRs will reveal the total number of records in the + zone, and also what types they are. This could be mitigated by + adding dummy entries, but certainly an upper limit can always be + found. + + Hash collisions may occur. If they do, it will be impossible to + prove the non-existence of the colliding domain - however, this is + fantastically unlikely, and, in any case, DNSSEC already relies on + SHA-1 to not collide. + + Responses to queries where QNAME equals an NSEC3 ownername that has + no other types may be undetectably changed from a NOERROR/NODATA + response to a NAME ERROR response. + + The Opt-In Flag (O) allows for unsigned names, in the form of + delegations to unsigned subzones, to exist within an otherwise signed + zone. All unsigned names are, by definition, insecure, and their + validity or existence cannot by cryptographically proven. + + In general: + Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilities are described in more detail in [16] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may be + undetectably altered by an attacker. Because of this, the primary + difference in security when using Opt-In is the loss of the ability + to prove the existence or nonexistence of an insecure delegation + + + +Laurie, et al. Expires August 5, 2006 [Page 19] + +Internet-Draft nsec3 February 2006 + + + within the span of an Opt-In NSEC3 record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). + + For example, if a resolver received the following response from the + example zone above: + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ + RRSIG DNSKEY + abcd... RRSIG NSEC3 ... + + Additional Section: + + The resolver would have no choice but to accept that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to using Opt-In, + and MAY choose to not support Opt-In at all. + + +12. References + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 20] + +Internet-Draft nsec3 February 2006 + + +12.1. 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] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [7] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [10] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [11] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain + Name System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + + [12] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + [13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", + RFC 3174, September 2001. + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 21] + +Internet-Draft nsec3 February 2006 + + +12.2. Informative References + + [14] Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)", + draft-vixie-dnssec-ter-01 (work in progress), June 2004. + + [15] Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data + Encodings.", draft-josefsson-rfc3548bis-00 (work in progress), + October 2005. + + [16] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + +Editorial Comments + + [Comment.1] Although, strictly speaking, the names *did* exist. + + [Comment.2] Note that this method makes it impossible to detect + (extremely unlikely) hash collisions. + + +Appendix A. Example Zone + + This is a zone showing its NSEC3 records. They can also be used as + test vectors for the hash algorithm. + + The data in the example zone is currently broken, as it uses a + different base32 alphabet. This shall be fixed in the next release. + + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 ) + 3600 RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + 3600 MX 1 xx.example. + + + +Laurie, et al. Expires August 5, 2006 [Page 22] + +Internet-Draft nsec3 February 2006 + + + 3600 RRSIG MX 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l + NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU + S/o/g5C8VM6ftQ== ) + 3600 DNSKEY 257 3 5 ( + AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX + cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 + zsYKWJ7BvR2894hX + ) ; Key ID = 21960 + 3600 DNSKEY 256 3 5 ( + AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU + 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL + ExXT48OGGdbfIme5 + ) ; Key ID = 62699 + 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z + xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx + mTkunTYzqWJrmQ== ) + 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( + 20050612112304 21960 example. + SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk + ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik + 3w7ZY2UWyYIvpw== ) + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 ( + deadbeaf + 7nomf47k3vlidh4vxahhpp47l3tgv7a2 + NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5 + Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ + sb7KfbaUo/vzAg== ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 ( + deadbeaf + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA + ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo + MEFQmc/gEuxojA== ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B + 766A6A4837206C ) + 3600 RRSIG DS 5 2 3600 20050712112304 ( + + + +Laurie, et al. Expires August 5, 2006 [Page 23] + +Internet-Draft nsec3 February 2006 + + + 20050612112304 62699 example. + QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn + cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 + 0kx7rGKTc3RQDA== ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU + 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq + ZXW5S+1VjMZYzQ== ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk + tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg + VGNmbgPnqDVPiA== ) + 3600 AAAA 2001:db8:0:0:0:0:f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV + ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns + l5/UqLCJJ9BDMg== ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 ( + deadbeaf + gmnfcccja7wkax3iv26bs75myptje3qk + MX DNSKEY NS SOA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D + C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R + MOiKMSHozVebqw== ) + gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 ( + deadbeaf + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6 + DS NS NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/ + ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW + OwQBGbOegrW/Zw== ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 ( + deadbeaf + + + +Laurie, et al. Expires August 5, 2006 [Page 24] + +Internet-Draft nsec3 February 2006 + + + kcll7fqfnisuhfekckeeqnmbbd4maanu + NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V + IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK + 94Zbq3k8lgdpZA== ) + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 ( + deadbeaf + n42hbhnjj333xdxeybycax5ufvntux5d + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA + IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx + TOLtc5jPrkL4zQ== ) + n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 ( + deadbeaf + nimwfwcnbeoodmsc6npv3vuaagaevxxu + A NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy + 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj + xFPFGRIW3wKnrA== ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 ( + deadbeaf + vhgwr2qgykdkf4m6iv6vkagbxozphazr + HINFO A AAAA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx + z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG + jL33Wm1p07TBdw== ) + ns1.example. 3600 A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb + BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr + nWWLepz1PjjShQ== ) + ns2.example. 3600 A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 + P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz + AkeTJu3J3auUiA== ) + vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 ( + deadbeaf + + + +Laurie, et al. Expires August 5, 2006 [Page 25] + +Internet-Draft nsec3 February 2006 + + + wbyijvpnyj33pcpi3i44ecnibnaj7eiw + HINFO A AAAA NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W + kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M + 5SNSHIyfpfsi6A== ) + *.w.example. 3600 MX 1 ai.example. + 3600 RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF + xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ + gQlgxEwhvQDEaQ== ) + x.w.example. 3600 MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w + lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP + U9VazOa1KEIq1w== ) + x.y.w.example. 3600 MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20050712112304 ( + 20050612112304 62699 example. + aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7 + uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF + 9VrQvJjwbllAfA== ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 ( + deadbeaf + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui + A NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN + ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd + oorBv4xkb0flXw== ) + xx.example. 3600 A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 + tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj + cxwCXWj82GVGdw== ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q + OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk + KMf4DgNBDj+dIQ== ) + 3600 AAAA 2001:db8:0:0:0:0:f00:baaa + 3600 RRSIG AAAA 5 2 3600 20050712112304 ( + + + +Laurie, et al. Expires August 5, 2006 [Page 26] + +Internet-Draft nsec3 February 2006 + + + 20050612112304 62699 example. + rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo + w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy + rzKKwb8J04/ILw== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1. answer + + A successful query to an authoritative server. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 27] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w + lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP + U9VazOa1KEIq1w== ) + + ;; Authority + example. 3600 IN NS ns1.example. + example. 3600 IN NS ns2.example. + example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 + tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj + cxwCXWj82GVGdw== ) + xx.example. 3600 IN AAAA 2001:db8::f00:baaa + xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo + w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy + rzKKwb8J04/ILw== ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb + BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr + nWWLepz1PjjShQ== ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 + P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz + AkeTJu3J3auUiA== ) + + + + +Laurie, et al. Expires August 5, 2006 [Page 28] + +Internet-Draft nsec3 February 2006 + + + The query returned an MX RRset for "x.w.example". The corresponding + RRSIG RR indicates that the MX RRset was signed by an "example" + DNSKEY with algorithm 5 and key tag 62699. The resolver needs the + corresponding DNSKEY RR in order to authenticate this answer. The + discussion below describes how a resolver might obtain this DNSKEY + RR. + + The RRSIG RR indicates the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG RR's labels field value of 3 indicates that the + answer was not the result of wildcard expansion. The "x.w.example" + MX RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +B.1.1. Authenticating the Example DNSKEY RRset + + This example shows the logical authentication process that starts + from a configured root DNSKEY RRset (or DS RRset) and moves down the + tree to authenticate the desired "example" DNSKEY RRset. Note that + the logical order is presented for clarity. An implementation may + choose to construct the authentication as referrals are received or + to construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RRset for the + root zone (or a configured DS RRset for the root zone). The resolver + checks whether this configured DNSKEY RRset is present in the root + DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY + RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the + root DNSKEY RRset, and whether the signature lifetime is valid. If + all these conditions are met, all keys in the DNSKEY RRset are + considered authenticated. The resolver then uses one (or more) of + the root DNSKEY RRs to authenticate the "example" DS RRset. Note + that the resolver may have to query the root zone to obtain the root + DNSKEY RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + + + +Laurie, et al. Expires August 5, 2006 [Page 29] + +Internet-Draft nsec3 February 2006 + + + DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +B.2. Name Error + + An authoritative name error. The NSEC3 RRs prove that the name does + not exist and that no covering wildcard exists. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 30] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + a.c.x.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb + MX NSEC3 RRSIG ) + 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA + ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo + MEFQmc/gEuxojA== ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + vhgwr2qgykdkf4m6iv6vkagbxozphazr + HINFO A AAAA NSEC3 RRSIG ) + nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx + z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG + jL33Wm1p07TBdw== ) + ;; Additional + ;; (empty) + + The query returned two NSEC3 RRs that prove that the requested data + does not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are + authenticated in a manner identical to that of the MX RRset discussed + + + +Laurie, et al. Expires August 5, 2006 [Page 31] + +Internet-Draft nsec3 February 2006 + + + above. At least one of the owner names of the NSEC3 RRs will match + the closest encloser. At least one of the NSEC3 RRs prove that there + exists no longer name. At least one of the NSEC3 RRs prove that + there exists no wildcard RRsets that should have been expanded. The + closest encloser can be found by hashing the apex ownername (The SOA + RR's ownername, or the ownername of the DNSKEY RRset referred by an + RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and + if that fails, continue by adding labels. In other words, the + resolver first hashes example, checks for a matching NSEC3 ownername, + then hashes w.example, checks, and finally hashes w.x.example and + checks. + + In the above example, the name 'x.w.example' hashes to + '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might + be the closest encloser. To prove that 'c.x.w.example' and + '*.x.w.example' do not exists, these names are hashed to respectively + 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and + 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that + these hashed ownernames do not exists, since the names are within the + given intervals. + +B.3. No Data Error + + A "no data" response. The NSEC3 RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 32] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui + A NSEC3 RRSIG ) + wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN + ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd + oorBv4xkb0flXw== ) + ;; Additional + ;; (empty) + + The query returned an NSEC3 RR that proves that the requested name + exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"), + but the requested RR type does not exist (type MX is absent in the + type code list of the NSEC RR). The negative reply is authenticated + by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner + identical to that of the MX RRset discussed above. + +B.3.1. No Data Error, Empty Non-Terminal + + A "no data" response because of an empty non-terminal. The NSEC3 RR + proves that the name exists and that the requested RR type does not. + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 33] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + y.w.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + kcll7fqfnisuhfekckeeqnmbbd4maanu + NSEC3 RRSIG ) + jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V + IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK + 94Zbq3k8lgdpZA== ) + + The query returned an NSEC3 RR that proves that the requested name + exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"), + but the requested RR type does not exist (Type A is absent in the + type-bit-maps of the NSEC3 RR). The negative reply is authenticated + by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner + identical to that of the MX RRset discussed above. Note that, unlike + generic empty non terminal proof using NSECs, this is identical to + proving a No Data Error. This example is solely mentioned to be + complete. + +B.4. Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + +Laurie, et al. Expires August 5, 2006 [Page 34] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR DO RCODE=0 + ;; + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 IN DS 58470 5 1 ( + 3079F1593EBAD6DC121E202A8B766A6A4837 + 206C ) + a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn + cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 + 0kx7rGKTc3RQDA== ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + The query returned a referral to the signed "a.example." zone. The + DS RR is authenticated in a manner identical to that of the MX RRset + discussed above. This DS RR is used to authenticate the "a.example" + DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +B.5. Referral to Unsigned Zone using the Opt-In Flag + + The NSEC3 RR proves that nothing for this delegation was signed in + the parent zone. There is no proof that the delegation exists + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 35] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 ( + deadbeaf + n42hbhnjj333xdxeybycax5ufvntux5d + MX NSEC3 RRSIG ) + kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA + IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx + TOLtc5jPrkL4zQ== ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + The query returned a referral to the unsigned "b.example." zone. The + NSEC3 proves that no authentication leads from "example" to + "b.example", since the hash of "b.example" + ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and + the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +B.6. Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC3 RR proves that + no closer match exists in the zone. + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 36] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( + 20050612112304 62699 example. + sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF + xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ + gQlgxEwhvQDEaQ== ) + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l + m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d + 1SH5r/wfjuCg+g== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU + 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq + ZXW5S+1VjMZYzQ== ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( + 20050612112304 62699 example. + PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV + ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns + l5/UqLCJJ9BDMg== ) + + The query returned an answer that was produced as a result of + wildcard expansion. The answer section contains a wildcard RRset + expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + + + +Laurie, et al. Expires August 5, 2006 [Page 37] + +Internet-Draft nsec3 February 2006 + + + signed by an "example" DNSKEY with algorithm 5 and key tag 62699. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC3 proves that no closer match (exact or closer wildcard) + could have been used to answer this query, and the NSEC3 RR must also + be authenticated before the answer is considered valid. + +B.7. Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC3 RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 38] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + 5pe7ctl7pfs2cilroy5dcofx4rcnlypd + MX NSEC3 RRSIG ) + zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt + 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny + OcFlrPGPMm48/A== ) + ;; Additional + ;; (empty) + + The query returned NSEC3 RRs that prove that the requested data does + not exist and no wildcard applies. The negative reply is + authenticated by verifying both NSEC3 RRs. + +B.8. DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 39] + +Internet-Draft nsec3 February 2006 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( + 20050612112304 62699 example. + RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK + mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g + qYIt90txzE/4+g== ) + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 ( + deadbeaf + gmnfcccja7wkax3iv26bs75myptje3qk + MX DNSKEY NS SOA NSEC3 RRSIG ) + dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 ( + 5 2 3600 20050712112304 + 20050612112304 62699 example. + VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D + C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R + MOiKMSHozVebqw== ) + + ;; Additional + ;; (empty) + + The query returned NSEC RRs that shows the requested was answered by + a child server ("example" server). The NSEC RR indicates the + presence of an SOA RR, showing that the answer is from the child . + Queries for the "example" DS RRset should be sent to the parent + servers ("root" servers). + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 40] + +Internet-Draft nsec3 February 2006 + + +Authors' Addresses + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + Phone: +44 (20) 8735 0686 + Email: ben@algroup.co.uk + + + Geoffrey Sisson + Nominet + + + Roy Arends + Nominet + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Laurie, et al. Expires August 5, 2006 [Page 41] + +Internet-Draft nsec3 February 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Laurie, et al. Expires August 5, 2006 [Page 42] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt new file mode 100644 index 0000000..90d1a06 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt @@ -0,0 +1,840 @@ + + + +Network Working Group R. Austein +Internet-Draft ISC +Expires: July 15, 2006 January 11, 2006 + + + DNS Name Server Identifier Option (NSID) + draft-ietf-dnsext-nsid-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 15, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. While existing ad-hoc + mechanism allow an operator to send follow-up queries when it is + necessary to debug such a configuration, the only completely reliable + way to obtain the identity of the name server which responded is to + have the name server include this information in the response itself. + This note defines a protocol extension to support this functionality. + + + +Austein Expires July 15, 2006 [Page 1] + +Internet-Draft DNS NSID January 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 + 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 + 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 + 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 + 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 + 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 + 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 2] + +Internet-Draft DNS NSID January 2006 + + +1. Introduction + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. + + Existing ad-hoc mechanisms allow an operator to send follow-up + queries when it is necessary to debug such a configuration, but there + are situations in which this is not a totally satisfactory solution, + since anycast routing may have changed, or the server pool in + question may be behind some kind of extremely dynamic load balancing + hardware. Thus, while these ad-hoc mechanisms are certainly better + than nothing (and have the advantage of already being deployed), a + better solution seems desirable. + + Given that a DNS query is an idempotent operation with no retained + state, it would appear that the only completely reliable way to + obtain the identity of the name server which responded to a + particular query is to have that name server include identifying + information in the response itself. This note defines a protocol + enhancement to achieve this. + +1.1. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 3] + +Internet-Draft DNS NSID January 2006 + + +2. Protocol + + This note uses an EDNS [RFC2671] option to signal the resolver's + desire for information identifying the name server and to hold the + name server's response, if any. + +2.1. Resolver Behavior + + A resolver signals its desire for information identifying a name + server by sending an empty NSID option (Section 2.3) in an EDNS OPT + pseudo-RR in the query message. + + The resolver MUST NOT include any NSID payload data in the query + message. + + The semantics of an NSID request are not transitive. That is: the + presence of an NSID option in a query is a request that the name + server which receives the query identify itself. If the name server + side of a recursive name server receives an NSID request, the client + is asking the recursive name server to identify itself; if the + resolver side of the recursive name server wishes to receive + identifying information, it is free to add NSID requests in its own + queries, but that is a separate matter. + +2.2. Name Server Behavior + + A name server which understands the NSID option and chooses to honor + a particular NSID request responds by including identifying + information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR + in the response message. + + The name server MUST ignore any NSID payload data that might be + present in the query message. + + The NSID option is not transitive. A name server MUST NOT send an + NSID option back to a resolver which did not request it. In + particular, while a recursive name server may choose to add an NSID + option when sending a query, this has no effect on the presence or + absence of the NSID option in the recursive name server's response to + the original client. + + As stated in Section 2.1, this mechanism is not restricted to + authoritative name servers; the semantics are intended to be equally + applicable to recursive name servers. + +2.3. The NSID Option + + The OPTION-CODE for the NSID option is [TBD]. + + + +Austein Expires July 15, 2006 [Page 4] + +Internet-Draft DNS NSID January 2006 + + + The OPTION-DATA for the NSID option is an opaque byte string the + semantics of which are deliberately left outside the protocol. See + Section 3.1 for discussion. + +2.4. Presentation Format + + User interfaces MUST read and write the content of the NSID option as + a sequence of hexadecimal digits, two digits per payload octet. + + The NSID payload is binary data. Any comparison between NSID + payloads MUST be a comparison of the raw binary data. Copy + operations MUST NOT assume that the raw NSID payload is null- + terminated. Any resemblance between raw NSID payload data and any + form of text is purely a convenience, and does not change the + underlying nature of the payload data. + + See Section 3.3 for discussion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 5] + +Internet-Draft DNS NSID January 2006 + + +3. Discussion + + This section discusses certain aspects of the protocol and explains + considerations that led to the chosen design. + +3.1. The NSID Payload + + The syntax and semantics of the content of the NSID option is + deliberately left outside the scope of this specification. This + section describe some of the kinds of data that server administrators + might choose to provide as the content of the NSID option, and + explains the reasoning behind choosing a simple opaque byte string. + + There are several possibilities for the payload of the NSID option: + + o It could be the "real" name of the specific name server within the + name server pool. + + o It could be the "real" IP address (IPv4 or IPv6) of the name + server within the name server pool. + + o It could be some sort of pseudo-random number generated in a + predictable fashion somehow using the server's IP address or name + as a seed value. + + o It could be some sort of probabilisticly unique identifier + initially derived from some sort of random number generator then + preserved across reboots of the name server. + + o It could be some sort of dynamicly generated identifier so that + only the name server operator could tell whether or not any two + queries had been answered by the same server. + + o It could be a blob of signed data, with a corresponding key which + might (or might not) be available via DNS lookups. + + o It could be a blob of encrypted data, the key for which could be + restricted to parties with a need to know (in the opinion of the + server operator). + + o It could be an arbitrary string of octets chosen at the discretion + of the name server operator. + + Each of these options has advantages and disadvantages: + + o Using the "real" name is simple, but the name server may not have + a "real" name. + + + + +Austein Expires July 15, 2006 [Page 6] + +Internet-Draft DNS NSID January 2006 + + + o Using the "real" address is also simple, and the name server + almost certainly does have at least one non-anycast IP address for + maintenance operations, but the operator of the name server may + not be willing to divulge its non-anycast address. + + o Given that one common reason for using anycast DNS techniques is + an attempt to harden a critical name server against denial of + service attacks, some name server operators are likely to want an + identifier other than the "real" name or "real" address of the + name server instance. + + o Using a hash or pseudo-random number can provide a fixed length + value that the resolver can use to tell two name servers apart + without necessarily being able to tell where either one of them + "really" is, but makes debugging more difficult if one happens to + be in a friendly open environment. Furthermore, hashing might not + add much value, since a hash based on an IPv4 address still only + involves a 32-bit search space, and DNS names used for servers + that operators might have to debug at 4am tend not to be very + random. + + o Probabilisticly unique identifiers have similar properties to + hashed identifiers, but (given a sufficiently good random number + generator) are immune to the search space issues. However, the + strength of this approach is also its weakness: there is no + algorithmic transformation by which even the server operator can + associate name server instances with identifiers while debugging, + which might be annoying. This approach also requires the name + server instance to preserve the probabilisticly unique identifier + across reboots, but this does not appear to be a serious + restriction, since authoritative nameservers almost always have + some form of nonvolatile storage in any case, and in the rare case + of a name server that does not have any way to store such an + identifier, nothing terrible will happen if the name server just + generates a new identifier every time it reboots. + + o Using an arbitrary octet string gives name server operators yet + another thing to configure, or mis-configure, or forget to + configure. Having all the nodes in an anycast name server + constellation identify themselves as "My Name Server" would not be + particularly useful. + + Given all of the issues listed above, there does not appear to be a + single solution that will meet all needs. Section 2.3 therefore + defines the NSID payload to be an opaque byte string and leaves the + choice up to the implementor and name server operator. The following + guidelines may be useful to implementors and server operators: + + + + +Austein Expires July 15, 2006 [Page 7] + +Internet-Draft DNS NSID January 2006 + + + o Operators for whom divulging the unicast address is an issue could + use the raw binary representation of a probabilisticly unique + random number. This should probably be the default implementation + behavior. + + o Operators for whom divulging the unicast address is not an issue + could just use the raw binary representation of a unicast address + for simplicity. This should only be done via an explicit + configuration choice by the operator. + + o Operators who really need or want the ability to set the NSID + payload to an arbitrary value could do so, but this should only be + done via an explicit configuration choice by the operator. + + This approach appears to provide enough information for useful + debugging without unintentionally leaking the maintenance addresses + of anycast name servers to nogoodniks, while also allowing name + server operators who do not find such leakage threatening to provide + more information at their own discretion. + +3.2. NSID Is Not Transitive + + As specified in Section 2.1 and Section 2.2, the NSID option is not + transitive. This is strictly a hop-by-hop mechanism. + + Most of the discussion of name server identification to date has + focused on identifying authoritative name servers, since the best + known cases of anycast name servers are a subset of the name servers + for the root zone. However, given that anycast DNS techniques are + also applicable to recursive name servers, the mechanism may also be + useful with recursive name servers. The hop-by-hop semantics support + this. + + While there might be some utility in having a transitive variant of + this mechanism (so that, for example, a stub resolver could ask a + recursive server to tell it which authoritative name server provided + a particular answer to the recursive name server), the semantics of + such a variant would be more complicated, and are left for future + work. + +3.3. User Interface Issues + + Given the range of possible payload contents described in + Section 3.1, it is not possible to define a single presentation + format for the NSID payload that is efficient, convenient, + unambiguous, and aesthetically pleasing. In particular, while it is + tempting to use a presentation format that uses some form of textual + strings, attempting to support this would significantly complicate + + + +Austein Expires July 15, 2006 [Page 8] + +Internet-Draft DNS NSID January 2006 + + + what's intended to be a very simple debugging mechanism. + + In some cases the content of the NSID payload may be binary data + meaningful only to the name server operator, and may not be + meaningful to the user or application, but the user or application + must be able to capture the entire content anyway in order for it to + be useful. Thus, the presentation format must support arbitrary + binary data. + + In cases where the name server operator derives the NSID payload from + textual data, a textual form such as US-ASCII or UTF-8 strings might + at first glance seem easier for a user to deal with. There are, + however, a number of complex issues involving internationalized text + which, if fully addressed here, would require a set of rules + significantly longer than the rest of this specification. See + [RFC2277] for an overview of some of these issues. + + It is much more important for the NSID payload data to be passed + unambiguously from server administrator to user and back again than + it is for the payload data data to be pretty while in transit. In + particular, it's critical that it be straightforward for a user to + cut and paste an exact copy of the NSID payload output by a debugging + tool into other formats such as email messages or web forms without + distortion. Hexadecimal strings, while ugly, are also robust. + +3.4. Truncation + + In some cases, adding the NSID option to a response message may + trigger message truncation. This specification does not change the + rules for DNS message truncation in any way, but implementors will + need to pay attention to this issue. + + Including the NSID option in a response is always optional, so this + specification never requires name servers to truncate response + messages. + + By definition, a resolver that requests NSID responses also supports + EDNS, so a resolver that requests NSID responses can also use the + "sender's UDP payload size" field of the OPT pseudo-RR to signal a + receive buffer size large enough to make truncation unlikely. + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 9] + +Internet-Draft DNS NSID January 2006 + + +4. IANA Considerations + + This mechanism requires allocation of one ENDS option code for the + NSID option (Section 2.3). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 10] + +Internet-Draft DNS NSID January 2006 + + +5. Security Considerations + + This document describes a channel signaling mechanism, intended + primarily for debugging. Channel signaling mechanisms are outside + the scope of DNSSEC per se. Applications that require integrity + protection for the data being signaled will need to use a channel + security mechanism such as TSIG [RFC2845]. + + Section 3.1 discusses a number of different kinds of information that + a name server operator might choose to provide as the value of the + NSID option. Some of these kinds of information are security + sensitive in some environments. This specification deliberately + leaves the syntax and semantics of the NSID option content up to the + implementation and the name server operator. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 11] + +Internet-Draft DNS NSID January 2006 + + +6. Acknowledgements + + Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve + Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, + Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and + Suzanne Woolf. Apologies to anyone inadvertently omitted from the + above list. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 12] + +Internet-Draft DNS NSID January 2006 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + +7.2. Informative References + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", RFC 2277, BCP 18, January 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 13] + +Internet-Draft DNS NSID January 2006 + + +Author's Address + + Rob Austein + ISC + 950 Charter Street + Redwood City, CA 94063 + USA + + Email: sra@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Expires July 15, 2006 [Page 14] + +Internet-Draft DNS NSID January 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Austein Expires July 15, 2006 [Page 15] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt index b5aaad2..a598826 100644 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt @@ -1380,7 +1380,7 @@ Appendix B. Document History to the RFC editor. - The version you are reading is tagged as $Revision: 1.1.232.1 $. + The version you are reading is tagged as $Revision: 1.1.230.1 $. Text between square brackets, other than references, are editorial diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt new file mode 100644 index 0000000..7cb9063 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt @@ -0,0 +1,730 @@ + + + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Expires: July 14, 2006 January 10, 2006 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-02 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 14, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against single key compromise of a key in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor. + + This mechanism, if adopted, will require changes to resolver + management behavior (but not resolver resolution behavior), and the + + + +StJohns Expires July 14, 2006 [Page 1] + +Internet-Draft trustanchor-update January 2006 + + + addition of a single flag bit to the DNSKEY record. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 + 2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 + 2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8 + 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9 + 5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 + 5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9 + 5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 + 7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 + 7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 + 7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . . . 13 + + + + + + + + + + + + + + +StJohns Expires July 14, 2006 [Page 2] + +Internet-Draft trustanchor-update January 2006 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the + community has come to the realization that there will not be one + signed name space, but rather islands of signed name space each + originating from specific points (i.e. 'trust points') in the DNS + tree. Each of those islands will be identified by the trust point + name, and validated by at least one associated public key. For the + purpose of this document we'll call the association of that name and + a particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key replacement/ + rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1. Compliance Nomenclature + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + +1.2. Changes since -00 + + Added the concept of timer triggered resolver queries to refresh the + + + +StJohns Expires July 14, 2006 [Page 3] + +Internet-Draft trustanchor-update January 2006 + + + resolvers view of the trust anchor key RRSet. + + Re-submitted expired draft as -01. Updated DNSSEC RFC References. + + Draft -02. Added the IANA Considerations section. Added text to + describe what happens if all trust anchors at a trust point are + deleted. + + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a new SEP key is added to a trust point + DNSKEY RRSet, and when that RRSet is validated by an existing trust + anchor, then the new key can be added to the set of trust anchors. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example assuming a single key + compromise, an attacker could add a new key and revoke all the other + old keys. + +2.1. Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a self- + signed RRSet and the key has the REVOKE bit (see Section 6 below) set + to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this + key as a trust anchor or for any other purposes except validating the + RRSIG over the DNSKEY RRSet specifically for the purpose of + validating the revocation. Unlike the 'Add' operation below, + revocation is immediate and permanent upon receipt of a valid + revocation at the resolver. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. [msj3] + + In the given example, the attacker could revoke B because it has + + + +StJohns Expires July 14, 2006 [Page 4] + +Internet-Draft trustanchor-update January 2006 + + + knowledge of B's private key, but could not revoke A. + +2.2. Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in the both + the attacker and owner being able to sign data in the zone and have + it accepted as valid by resolvers. + + To mitigate, but not completely solve, this problem, we add a hold- + down time to the addition of the trust anchor. When the resolver + sees a new SEP key in a validated trust point DNSKEY RRSet, the + resolver starts an acceptance timer, and remembers all the keys that + validated the RRSet. If the resolver ever sees the DNSKEY RRSet + without the new key but validly signed, it stops the acceptance + process and resets the acceptance timer. If all of the keys which + were originally used to validate this key are revoked prior to the + timer expiring, the resolver stops the acceptance process and resets + the timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3. Remove Hold-down + + A new key which has been seen by the resolver, but hasn't reached + it's add hold-down time, MAY be removed from the DNSKEY RRSet by the + + + +StJohns Expires July 14, 2006 [Page 5] + +Internet-Draft trustanchor-update January 2006 + + + zone owner. If the resolver sees a validated DNSKEY RRSet without + this key, it waits for the remove hold-down time and then, if the key + hasn't reappeared, SHOULD discard any information about the key. + +2.4. Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + RRSet or half the RRSIG expiration interval. The expiration interval + is the amount of time from when the RRSIG was last retrieved until + the expiration time in the RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. + +2.5. Resolver Parameters + +2.5.1. Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the TTL + of the first trust point DNSKEY RRSet which contained the key, + whichever is greater. This ensures that at least two validated + DNSKEY RRSets which contain the new key MUST be seen by the resolver + prior to the key's acceptance. + +2.5.2. Remove Hold-Down Time + + The remove hold-down time is 30 days. + +2.5.3. Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validing the revocation. + + + + + +StJohns Expires July 14, 2006 [Page 6] + +Internet-Draft trustanchor-update January 2006 + + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + [msj1] This is the state of a trust point key as seen from the + resolver. The column on the left indicates the current state. The + header at the top shows the next state. The intersection of the two + shows the event that will cause the state to transition from the + current state to the next. + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + +4.1. Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after its been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with its + "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + + + + + +StJohns Expires July 14, 2006 [Page 7] + +Internet-Draft trustanchor-update January 2006 + + +4.2. States + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but hasn't yet been + seen at the resolver. + AddPend The key has been seen at the resolver, has its 'SEP' bit set, + and has been included in a validated DNSKEY RRSet. There is a + hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. [Discussion + item: Should a missing key be considered revoked after some period + of time?] + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. + +4.3. Trust Point Deletion + + A trust point which has all of its trust anchors revoked is + considered deleted and is treated as if the trust point was never + configured. If there are no superior trust points, data at and below + the deleted trust point are considered insecure. If there there ARE + superior trust points, data at and below the deleted trust point are + evaluated with respect to the superior trust point. + + +5. Scenarios + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + + + +StJohns Expires July 14, 2006 [Page 8] + +Internet-Draft trustanchor-update January 2006 + + + Since the stand-by key is not in active signing use, the associated + private key may (and SHOULD) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +5.1. Adding A Trust Anchor + + Assume an existing trust anchor key 'A'. + 1. Generate a new key pair. + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while. + +5.2. Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revolcation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator SHOULD include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + +5.3. Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been + in the DNSKEY RRSet and is a valid trust anchor, but wasn't being + used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator SHOULD include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +5.4. Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 5.3) + above assuming 'A' is the active key. + + + +StJohns Expires July 14, 2006 [Page 9] + +Internet-Draft trustanchor-update January 2006 + + +5.5. Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 5.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' SHOULD continue to be + included in the RRSet for the remove hold-down time. + + +6. IANA Considerations + + The IANA will need to assign a bit in the DNSKEY flags field (see + section 4.3 of [RFC3755]) for the REVOKE bit. There are no other + IANA actions required. + + +7. Security Considerations + +7.1. Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +7.2. Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + + + + +StJohns Expires July 14, 2006 [Page 10] + +Internet-Draft trustanchor-update January 2006 + + +7.3. Dynamic Updates + + Allowing a resolver to update its trust anchor set based in-band key + information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +8. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +Editorial Comments + + [msj1] msj: N.B. This table is preliminary and will be revised to + match implementation experience. For example, should there + be a state for "Add hold-down expired, but haven't seen the + new RRSet"? + + [msj2] msj: To be assigned. + + [msj3] msj: For discussion: What's the implementation guidance for + resolvers currently with respect to the non-assigned flag + bits? If they consider the flag bit when doing key matching + at the trust anchor, they won't be able to match. + + + + + + +StJohns Expires July 14, 2006 [Page 11] + +Internet-Draft trustanchor-update January 2006 + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + Email: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Expires July 14, 2006 [Page 12] + +Internet-Draft trustanchor-update January 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +StJohns Expires July 14, 2006 [Page 13] + + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt new file mode 100644 index 0000000..00476ae --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt @@ -0,0 +1,522 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +UPDATES RFC 2845 Motorola Laboratories +Expires: July 2006 January 2006 + + HMAC SHA TSIG Algorithm Identifiers + ---- --- ---- --------- ----------- + <draft-ietf-dnsext-tsig-sha-06.txt> + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + Use of the Domain Name System TSIG resource record requires + specification of a cryptographic message authentication code. + Currently identifiers have been specified only for the HMAC MD5 + (Message Digest) and GSS (Generic Security Service) TSIG algorithms. + This document standardizes identifiers and implementation + requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG + algorithms and standardizes how to specify and handle the truncation + of HMAC values in TSIG. + + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + +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 + 3.1 Truncation Specification...............................5 + + 4. TSIG Truncation Policy and Error Provisions.............6 + + 5. IANA Considerations.....................................7 + 6. Security Considerations.................................7 + 7. Copyright and Disclaimer................................7 + + 8. Normative References....................................8 + 9. Informative References..................................8 + + Author's Address...........................................9 + Additional IPR Provisions..................................9 + Expiration and File Name...................................9 + + + + + + + + + + + + + + + + + + + + + + + + + +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 (Domain Name System [STD 13]) 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 the Generic Security + Service (GSS) [RFC 3645]. + + It should be noted that use of TSIG presumes prior agreement, between + the resolver and server involved, as to the algorithm and key to be + used. + + In Section 2, this document specifies additional names for TSIG + authentication algorithms based on US NIST SHA (United States, + National Institute of Science and Technology, Secure Hash Algorithm) + algorithms and HMAC and specifies the implementation requirements for + those algorithms. + + In Section 3, this document specifies the effect of inequality + between the normal output size of the specified hash function and the + length of MAC (message authentication code) data given in the TSIG + RR. In particular, it specifies that a shorter length field value + specifies truncation and a longer length field is an error. + + In Section 4, policy restrictions and implications related to + truncation and a new error code to indicate truncation shorter than + permitted by policy are described and specified. + + The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as + defined in [RFC 2119]. + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +2. Algorithms and Identifiers + + TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS + queries and responses. They are intended to be efficient symmetric + authentication codes based on a shared secret. (Asymmetric signatures + can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) + can be used for transaction signatures.) Used with a strong hash + function, HMAC [RFC 2104] provides a way to calculate such symmetric + authentication codes. The only specified HMAC based TSIG algorithm + identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. + + The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as + compared with the 128 bits for MD5, and additional hash algorithms in + the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, + and 512 bits, may be preferred in some cases particularly since + increasingly successful cryptanalytic attacks are being made on the + shorter hashes. + + Use of TSIG between a DNS resolver and server is by mutual agreement. + That agreement can include the support of additional algorithms and + criteria as to which algorithms and truncations are acceptable, + subject to the restriction and guidelines in Section 3 and 4 below. + Key agreement can be by the TKEY mechanism [RFC 2930] or other + mutually agreeable method. + + The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are + included in the table below for convenience. Implementations which + support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY + implement gss-tsig and the other algorithms listed below. + + Mandatory HMAC-MD5.SIG-ALG.REG.INT + Optional gss-tsig + Mandatory hmac-sha1 + Optional hmac-sha224 + Mandatory hmac-sha256 + Optional hamc-sha384 + Optional hmac-sha512 + + SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. + + + + + + + + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +3. Specifying Truncation + + When space is at a premium and the strength of the full length of an + HMAC is not needed, it is reasonable to truncate the HMAC output and + use the truncated value for authentication. HMAC SHA-1 truncated to + 96 bits is an option available in several IETF protocols including + IPSEC and TLS. + + The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the + size of the MAC field in octets. But [RFC 2845] does not specify what + to do if this MAC size differs from the length of the output of HMAC + for a particular hash function. Truncation is indicated by a MAC size + less than the HMAC size as specified below. + + + +3.1 Truncation Specification + + The specification for TSIG handling is changed as follows: + + 1. If "MAC size" field is greater than HMAC output length: + This case MUST NOT be generated and if received MUST cause the + packet to be dropped and RCODE 1 (FORMERR) to be returned. + + 2. If "MAC size" field equals HMAC output length: + Operation is as described in [RFC 2845] with the entire output + HMAC output present. + + 3. "MAC size" field is less than HMAC output length but greater than + that specified in case 4 below: + This is sent when the signer has truncated the HMAC output to + an allowable length, as described in RFC 2104, taking initial + octets and discarding trailing octets. TSIG truncation can only be + to an integral number of octets. On receipt of a packet with + truncation thus indicated, the locally calculated MAC is similarly + truncated and only the truncated values compared for + authentication. The request MAC used when calculating the TSIG MAC + for a reply is the truncated request MAC. + + 4. "MAC size" field is less than the larger of 10 (octets) and half + the length of the hash function in use: + With the exception of certain TSIG error messages described in + RFC 2845 section 3.2 where it is permitted that the MAC size be + zero, this case MUST NOT be generated and if received MUST cause + the packet to be dropped and RCODE 1 (FORMERR) to be returned. The + size limit for this case can also, for the hash functions + mentioned in this document, be stated as less than half the hash + function length for hash functions other than MD5 and less than 10 + octets for MD5. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +4. TSIG Truncation Policy and Error Provisions + + Use of TSIG is by mutual agreement between a resolver and server. + Implicit in such "agreement" are criterion as to acceptable keys and + algorithms and, with the extensions in this document, truncations. + Note that it is common for implementations to bind the TSIG secret + key or keys that may be in place at a resolver and server to + particular algorithms. Thus such implementations only permit the use + of an algorithm if there is an associated key in place. Receipt of an + unknown, unimplemented, or disabled algorithm typically results in a + BADKEY error. + + Local policies MAY require the rejection of TSIGs even though they + use an algorithm for which implementation is mandatory. + + When a local policy permits acceptance of a TSIG with a particular + algorithm and a particular non-zero amount of truncation it SHOULD + also permit the use of that algorithm with lesser truncation (a + longer MAC) up to the full HMAC output. + + Regardless of a lower acceptable truncated MAC length specified by + local policy, a reply SHOULD be sent with a MAC at least as long as + that in the corresponding request unless the request specified a MAC + length longer than the HMAC output. + + Implementations permitting multiple acceptable algorithms and/or + truncations SHOULD permit this list to be ordered by presumed + strength and SHOULD allow different truncations for the same + algorithm to be treated as separate entities in this list. When so + implemented, policies SHOULD accept a presumed stronger algorithm and + truncation than the minimum strength required by the policy. + + If a TSIG is received with truncation which is permitted under + Section 3 above but the MAC is too short for the local policy in + force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +5. IANA Considerations + + This document, on approval for publication as a standards track RFC, + (1) registers the new TSIG algorithm identifiers listed in Section 2 + with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in + Section 4. [RFC 2845] + + + +6. Security Considerations + + For all of the message authentication code algorithms listed herein, + those producing longer values are believed to be stronger; however, + while there have been some arguments that mild truncation can + strengthen a MAC by reducing the information available to an + attacker, excessive truncation clearly weakens authentication by + reducing the number of bits an attacker has to try to break the + authentication by brute force [RFC 2104]. + + Significant progress has been made recently in cryptanalysis of hash + function of the type used herein, all of which ultimately derive from + the design of MD4. While the results so far should not effect HMAC, + the stronger SHA-1 and SHA-256 algorithms are being made mandatory + due to caution. + + See the Security Considerations section of [RFC 2845]. See also the + Security Considerations section of [RFC 2104] from which the limits + on truncation in this RFC were taken. + + + +7. Copyright and Disclaimer + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +8. Normative References + + [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US + Federal Information Processing Standard, with Change Notice 1, + February 2004. + + [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC + 1321, April 1992. + + [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February 1997. + + [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + + [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", + September 2004, + + [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms + (SHA)", draft-eastlake-sha2-*.txt, work in progress. + + [STD 13] + Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + + +9. Informative References. + + [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS + (TKEY RR)", RFC 2930, September 2000. + + [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction + Signatures ( SIG(0)s )", RFC 2931, September 2000. + + [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 8] + + +INTERNET-DRAFT HMAC-SHA TSIG Identifiers + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + + EMail: Donald.Eastlake@motorola.com + + + +Additional IPR Provisions + + 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. + + + +Expiration and File Name + + This draft expires in July 2006. + + Its file name is draft-ietf-dnsext-tsig-sha-06.txt + + + + + + + + +D. Eastlake 3rd [Page 9] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt new file mode 100644 index 0000000..9cf88a5 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt @@ -0,0 +1,1063 @@ +Internet-Draft dnsext-wcard January 9, 2006 + +DNSEXT Working Group E. Lewis +INTERNET DRAFT NeuStar +Expiration Date: July 9, 2006 January 9, 2006 +Updates RFC 1034, RFC 2672 + + The Role of Wildcards + in the Domain Name System + draft-ietf-dnsext-wcard-clarify-10.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that + any applicable patent or other IPR claims of which he or she is + aware have been or will be disclosed, and any of which he or she + becomes aware will be disclosed, in accordance with Section 6 of + BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + This Internet-Draft will expire on July 9, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This is an update to the wildcard definition of RFC 1034. The + interaction with wildcards and CNAME is changed, an error + condition removed, and the words defining some concepts central + to wildcards are changed. The overall goal is not to change + wildcards, but to refine the definition of RFC 1034. + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 1] + +Internet-Draft dnsext-wcard January 9, 2006 + +Table of Contents + +1. Introduction . . . . . . . . . . . . . . . . 3 +1 1 Motivation 3 +1 2 The Original Definition 3 +1 3 Roadmap to This Document 4 +1 3 1 New Terms 4 +1.3.2 Changed Text 5 +1.3.3 Considerations with Special Types 5 +1.4 Standards Terminology 5 +2. Wildcard Syntax . . . . . . . . . . . . . . . 6 +2.1 Identifying a Wildcard 6 +2.1.1 Wild Card Domain Name and Asterisk Label 6 +2.1.2 Asterisks and Other Characters 6 +2.1.3 Non-terminal Wild Card Domain Names 6 +2.2 Existence Rules 7 +2.2.1 An Example 7 +2.2.2 Empty Non-terminals 9 +2.2.3 Yet Another Definition of Existence 10 +2.3 When is a Wild Card Domain Name Not Special 10 +3. Impact of a Wild Card Domain Name On a Response . . . . . 10 +3.1 Step 2 10 +3.2 Step 3 11 +3.3 Part 'c' 11 +3.3.1 Closest Encloser and the Source of Synthesis 12 +3.3.2 Closest Encloser and Source of Synthesis Examples 12 +3.3.3 Type Matching 13 +4. Considerations with Special Types . . . . . . . . . 13 +4.1 SOA RRSet at a Wild Card Domain Name 13 +4.2 NS RRSet at a Wild Card Domain Name 14 +4.2.1 Discarded Notions 14 +4.3 CNAME RRSet at a Wild Card Domain Name 15 +4.4 DNAME RRSet at a Wild Card Domain Name 15 +4.5 SRV RRSet at a Wild Card Domain Name 16 +4.6 DS RRSet at a Wild Card Domain Name 16 +4.7 NSEC RRSet at a Wild Card Domain Name 17 +4.8 RRSIG at a Wild Card Domain Name 17 +4.9 Empty Non-terminal Wild Card Domain Name 17 +5. Security Considerations . . . . . . . . . . . . . 17 +6. IANA Considerations . . . . . . . . . . . . . 17 +7. References . . . . . . . . . . . . . 17 +8. Editor . . . . . . . . . . . . . 18 +9. Others Contributing to the Document . . . . . . . . 18 +10. Trailing Boilerplate . . . . . . . . . . . . . 19 + + + + + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 2] + +Internet-Draft dnsext-wcard January 9, 2006 + +1. Introduction + + In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the + synthesis of answers from special resource records called + wildcards. The definition in RFC 1034 is incomplete and has + proven to be confusing. This document describes the wildcard + synthesis by adding to the discussion and making limited + modifications. Modifications are made to close inconsistencies + that have led to interoperability issues. This description + does not expand the service intended by the original definition. + + Staying within the spirit and style of the original documents, + this document avoids specifying rules for DNS implementations + regarding wildcards. The intention is to only describe what is + needed for interoperability, not restrict implementation choices. + In addition, consideration is given to minimize any backwards + compatibility issues with implementations that comply with RFC + 1034's definition. + + This document is focused on the concept of wildcards as defined + in RFC 1034. Nothing is implied regarding alternative means of + synthesizing resource record sets, nor are alternatives discussed. + +1.1 Motivation + + Many DNS implementations diverge, in different ways, from the + original definition of wildcards. Although there is clearly a + need to clarify the original documents in light of this alone, + the impetus for this document lay in the engineering of the DNS + security extensions [RFC4033]. With an unclear definition of + wildcards the design of authenticated denial became entangled. + + This document is intended to limit its changes, documenting only + those based on implementation experience, and to remain as close + to the original document as possible. To reinforce that this + document is meant to clarify and adjust and not redefine wildcards, + relevant sections of RFC 1034 are repeated verbatim to facilitate + comparison of the old and new text. + +1.2 The Original Definition + + The definition of the wildcard concept is comprised by the + documentation of the algorithm by which a name server prepares + a response (in RFC 1034's section 4.3.2) and the way in which + a resource record (set) is identified as being a source of + synthetic data (section 4.3.3). + + This is the definition of the term "wildcard" as it appears in + RFC 1034, section 4.3.3. + + + +DNSEXT Working Group Expires July 9, 2006 [Page 3] + +Internet-Draft dnsext-wcard January 9, 2006 + +# In the previous algorithm, special treatment was given to RRs with +# owner names starting with the label "*". Such RRs are called +# wildcards. Wildcard RRs can be thought of as instructions for +# synthesizing RRs. When the appropriate conditions are met, the name +# server creates RRs with an owner name equal to the query name and +# contents taken from the wildcard RRs. + + This passage follows the algorithm in which the term wildcard + is first used. In this definition, wildcard refers to resource + records. In other usage, wildcard has referred to domain names, + and it has been used to describe the operational practice of + relying on wildcards to generate answers. It is clear from this + that there is a need to define clear and unambiguous terminology + in the process of discussing wildcards. + + The mention of the use of wildcards in the preparation of a + response is contained in step 3c of RFC 1034's section 4.3.2 + entitled "Algorithm." Note that "wildcard" does not appear in + the algorithm, instead references are made to the "*" label. + The portion of the algorithm relating to wildcards is + deconstructed in detail in section 3 of this document, this is + the beginning of the relevant portion of the "Algorithm." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if [...] +# the "*" label exists. + + The scope of this document is the RFC 1034 definition of + wildcards and the implications of updates to those documents, + such as DNSSEC. Alternate schemes for synthesizing answers are + not considered. (Note that there is no reference listed. No + document is known to describe any alternate schemes, although + there has been some mention of them in mailing lists.) + +1.3 Roadmap to This Document + + This document accomplishes these three items. + o Defines new terms + o Makes minor changes to avoid conflicting concepts + o Describes the actions of certain resource records as wildcards + +1.3.1 New Terms + + To help in discussing what resource records are wildcards, two + terms will be defined - "asterisk label" and "wild card domain + name". These are defined in section 2.1.1. + + To assist in clarifying the role of wildcards in the name server + algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest + encloser" are defined. These definitions are in section 3.3.2. + "Label match" is defined in section 3.2. + +DNSEXT Working Group Expires July 9, 2006 [Page 4] + +Internet-Draft dnsext-wcard January 9, 2006 + + The new terms are used to make discussions of wildcards clearer. + Terminology doesn't directly have an impact on implementations. + +1.3.2 Changed Text + + The definition of "existence" is changed superficially. This + change will not be apparent to implementations; it is needed to + make descriptions more precise. The change appears in section + 2.2.3. + + RFC 1034, section 4.3.3., seems to prohibit having two asterisk + labels in a wildcard owner name. With this document the + restriction is removed entirely. This change and its implications + are in section 2.1.3. + + The actions when a source of synthesis owns a CNAME RR are + changed to mirror the actions if an exact match name owns a + CNAME RR. This is an addition to the words in RFC 1034, + section 4.3.2, step 3, part c. The discussion of this is in + section 3.3.3. + + Only the latter change represents an impact to implementations. + The definition of existence is not a protocol impact. The change + to the restriction on names is unlikely to have an impact, as + RFC 1034 contained no specification on when and how to enforce the + restriction. + +1.3.3 Considerations with Special Types + + This document describes semantics of wildcard RRSets for + "interesting" types as well as empty non-terminal wildcards. + Understanding these situations in the context of wildcards has + been clouded because these types incur special processing if + they are the result of an exact match. This discussion is in + section 4. + + These discussions do not have an implementation impact, they cover + existing knowledge of the types, but to a greater level of detail. + +1.4 Standards Terminology + + This document does not use terms as defined in "Key words for use + in RFCs to Indicate Requirement Levels." [RFC2119] + + Quotations of RFC 1034 are denoted by a '#' in the leftmost + column. References to section "4.3.2" are assumed to refer + to RFC 1034's section 4.3.2, simply titled "Algorithm." + + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 5] + +Internet-Draft dnsext-wcard January 9, 2006 + +2. Wildcard Syntax + + The syntax of a wildcard is the same as any other DNS resource + record, across all classes and types. The only significant + feature is the owner name. + + Because wildcards are encoded as resource records with special + names, they are included in zone transfers and incremental zone + transfers[RFC1995] just as non-wildcard resource records are. + This feature has been under appreciated until discussions on + alternative approaches to wildcards appeared on mailing lists. + +2.1 Identifying a Wildcard + + To provide a more accurate description of wildcards, the + definition has to start with a discussion of the domain names + that appear as owners. Two new terms are needed, "Asterisk + Label" and "Wild Card Domain Name." + +2.1.1 Wild Card Domain Name and Asterisk Label + + A "wild card domain name" is defined by having its initial + (i.e., left-most or least significant) label be, in binary format: + + 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) + + The first octet is the normal label type and length for a 1 octet + long label, the second octet is the ASCII representation [RFC20] + for the '*' character. + + A descriptive name of a label equaling that value is an "asterisk + label." + + RFC 1034's definition of wildcard would be "a resource record + owned by a wild card domain name." + +2.1.2 Asterisks and Other Characters + + No label values other than that in section 2.1.1 are asterisk + labels, hence names beginning with other labels are never wild + card domain names. Labels such as 'the*' and '**' are not + asterisk labels so these labels do not start wild card domain + names. + +2.1.3 Non-terminal Wild Card Domain Names + + In section 4.3.3, the following is stated: + +# .......................... The owner name of the wildcard RRs is of +# the form "*.<anydomain>", where <anydomain> is any domain name. +# <anydomain> should not contain other * labels...................... + +DNSEXT Working Group Expires July 9, 2006 [Page 6] + +Internet-Draft dnsext-wcard January 9, 2006 + + The restriction is now removed. The original documentation of it + is incomplete and the restriction does not serve any purpose + given years of operational experience. + + There are three possible reasons for putting the restriction in + place, but none of the three has held up over time. One is + that the restriction meant that there would never be subdomains + of wild card domain names, but the restriciton as stated still + permits "example.*.example." for instance. Another is that + wild card domain names are not intended to be empty non-terminals, + but this situation does not disrupt the algorithm in 4.3.2. + Finally, "nested" wild card domain names are not ambiguous once + the concept of the closest encloser had been documented. + + A wild card domain name can have subdomains. There is no need + to inspect the subdomains to see if there is another asterisk + label in any subdomain. + + A wild card domain name can be an empty non-terminal. (See the + upcoming sections on empty non-terminals.) In this case, any + lookup encountering it will terminate as would any empty + non-terminal match. + +2.2 Existence Rules + + The notion that a domain name 'exists' is mentioned in the + definition of wildcards. In section 4.3.3 of RFC 1034: + +# Wildcard RRs do not apply: +# +... +# - When the query name or a name between the wildcard domain and +# the query name is know[n] to exist. For example, if a wildcard + + "Existence" is therefore an important concept in the understanding + of wildcards. Unfortunately, the definition of what exists, in RFC + 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is + taken at the definition of existence. + +2.2.1 An Example + + To illustrate what is meant by existence consider this complete + zone: + + + + + + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 7] + +Internet-Draft dnsext-wcard January 9, 2006 + + $ORIGIN example. + example. 3600 IN SOA <SOA RDATA> + example. 3600 NS ns.example.com. + example. 3600 NS ns.example.net. + *.example. 3600 TXT "this is a wild card" + *.example. 3600 MX 10 host1.example. + sub.*.example. 3600 TXT "this is not a wild card" + host1.example. 3600 A 192.0.4.1 + _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> + _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> + subdel.example. 3600 NS ns.example.com. + subdel.example. 3600 NS ns.example.net. + + A look at the domain names in a tree structure is helpful: + + | + -------------example------------ + / / \ \ + / / \ \ + / / \ \ + * host1 host2 subdel + | | | + | | | + sub _tcp _tcp + | | + | | + _ssh _ssh + + The following responses would be synthesized from one of the + wildcards in the zone: + + QNAME=host3.example. QTYPE=MX, QCLASS=IN + the answer will be a "host3.example. IN MX ..." + + QNAME=host3.example. QTYPE=A, QCLASS=IN + the answer will reflect "no error, but no data" + because there is no A RR set at '*.example.' + + QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN + the answer will be "foo.bar.example. IN TXT ..." + because bar.example. does not exist, but the wildcard + does. + + The following responses would not be synthesized from any of the + wildcards in the zone: + + QNAME=host1.example., QTYPE=MX, QCLASS=IN + because host1.example. exists + + QNAME=sub.*.example., QTYPE=MX, QCLASS=IN + because sub.*.example. exists + +DNSEXT Working Group Expires July 9, 2006 [Page 8] + +Internet-Draft dnsext-wcard January 9, 2006 + + QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN + because _tcp.host1.example. exists (without data) + + QNAME=host.subdel.example., QTYPE=A, QCLASS=IN + because subdel.example. exists (and is a zone cut) + + QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN + because *.example. exists + + The final example highlights one common misconception about + wildcards. A wildcard "blocks itself" in the sense that a + wildcard does not match its own subdomains. I.e. "*.example." + does not match all names in the "example." zone, it fails to + match the names below "*.example." To cover names under + "*.example.", another wild card domain name is needed - + "*.*.example." - which covers all but it's own subdomains. + +2.2.2 Empty Non-terminals + + Empty non-terminals [RFC2136, Section 7.16] are domain names + that own no resource records but have subdomains that do. In + section 2.2.1, "_tcp.host1.example." is an example of a empty + non-terminal name. Empty non-terminals are introduced by this + text in section 3.1 of RFC 1034: + +# The domain name space is a tree structure. Each node and leaf on +# the tree corresponds to a resource set (which may be empty). The +# domain system makes no distinctions between the uses of the +# interior nodes and leaves, and this memo uses the term "node" to +# refer to both. + + The parenthesized "which may be empty" specifies that empty non- + terminals are explicitly recognized, and that empty non-terminals + "exist." + + Pedantically reading the above paragraph can lead to an + interpretation that all possible domains exist - up to the + suggested limit of 255 octets for a domain name [RFC1035]. + For example, www.example. may have an A RR, and as far as is + practically concerned, is a leaf of the domain tree. But the + definition can be taken to mean that sub.www.example. also + exists, albeit with no data. By extension, all possible domains + exist, from the root on down. + + As RFC 1034 also defines "an authoritative name error indicating + that the name does not exist" in section 4.3.1, so this apparently + is not the intent of the original definition, justifying the + need for an updated definition in the next section. + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 9] + +Internet-Draft dnsext-wcard January 9, 2006 + +2.2.3 Yet Another Definition of Existence + + RFC1034's wording is fixed by the following paragraph: + + The domain name space is a tree structure. Nodes in the tree + either own at least one RRSet and/or have descendants that + collectively own at least one RRSet. A node may exist with no + RRSets only if it has descendents that do, this node is an empty + non-terminal. + + A node with no descendants is a leaf node. Empty leaf nodes do + not exist. + + Note that at a zone boundary, the domain name owns data, + including the NS RR set. In the delegating zone, the NS RR + set is not authoritative, but that is of no consequence here. + The domain name owns data, therefore, it exists. + +2.3 When is a Wild Card Domain Name Not Special + + When a wild card domain name appears in a message's query section, + no special processing occurs. An asterisk label in a query name + only matches a single, corresponding asterisk label in the + existing zone tree when the 4.3.2 algorithm is being followed. + + When a wild card domain name appears in the resource data of a + record, no special processing occurs. An asterisk label in that + context literally means just an asterisk. + +3. Impact of a Wild Card Domain Name On a Response + + RFC 1034's description of how wildcards impact response + generation is in its section 4.3.2. That passage contains the + algorithm followed by a server in constructing a response. + Within that algorithm, step 3, part 'c' defines the behavior of + the wildcard. + + The algorithm in section 4.3.2. is not intended to be pseudo-code, + i.e., its steps are not intended to be followed in strict order. + The "algorithm" is a suggested means of implementing the + requirements. As such, in step 3, parts a, b, and c, do not have + to be implemented in that order, provided that the result of the + implemented code is compliant with the protocol's specification. + +3.1 Step 2 + + Step 2 of section 4.3.2 reads: + +# 2. Search the available zones for the zone which is the nearest +# ancestor to QNAME. If such a zone is found, go to step 3, +# otherwise step 4. + +DNSEXT Working Group Expires July 9, 2006 [Page 10] + +Internet-Draft dnsext-wcard January 9, 2006 + + In this step, the most appropriate zone for the response is + chosen. The significance of this step is that it means all of + step 3 is being performed within one zone. This has significance + when considering whether or not an SOA RR can be ever be used for + synthesis. + +3.2 Step 3 + + Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. + But the beginning of the step is important and needs explanation. + +# 3. Start matching down, label by label, in the zone. The +# matching process can terminate several ways: + + The word 'matching' refers to label matching. The concept + is based in the view of the zone as the tree of existing names. + The query name is considered to be an ordered sequence of + labels - as if the name were a path from the root to the owner + of the desired data. (Which it is - 3rd paragraph of RFC 1034, + section 3.1.) + + The process of label matching a query name ends in exactly one of + three choices, the parts 'a', 'b', and 'c'. Either the name is + found, the name is below a cut point, or the name is not found. + + Once one of the parts is chosen, the other parts are not + considered. (E.g., do not execute part 'c' and then change + the execution path to finish in part 'b'.) The process of label + matching is also done independent of the query type (QTYPE). + + Parts 'a' and 'b' are not an issue for this clarification as they + do not relate to record synthesis. Part 'a' is an exact match + that results in an answer, part 'b' is a referral. + +3.3 Part 'c' + + The context of part 'c' is that the process of label matching the + labels of the query name has resulted in a situation in which + there is no corresponding label in the tree. It is as if the + lookup has "fallen off the tree." + +# c. If at some label, a match is impossible (i.e., the +# corresponding label does not exist), look to see if [...] +# the "*" label exists. + + To help describe the process of looking 'to see if [...] the "*" + label exists' a term has been coined to describe the last domain + (node) matched. The term is "closest encloser." + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 11] + +Internet-Draft dnsext-wcard January 9, 2006 + +3.3.1 Closest Encloser and the Source of Synthesis + + The closest encloser is the node in the zone's tree of existing + domain names that has the most labels matching the query name + (consecutively, counting from the root label downward). Each match + is a "label match" and the order of the labels is the same. + + The closest encloser is, by definition, an existing name in the + zone. The closest encloser might be an empty non-terminal or even + be a wild card domain name itself. In no circumstances is the + closest encloser to be used to synthesize records for the current + query. + + The source of synthesis is defined in the context of a query + process as that wild card domain name immediately descending + from the closest encloser, provided that this wild card domain + name exists. "Immediately descending" means that the source + of synthesis has a name of the form: + <asterisk label>.<closest encloser>. + A source of synthesis does not guarantee having a RRSet to use + for synthesis. The source of synthesis could be an empty + non-terminal. + + If the source of synthesis does not exist (not on the domain + tree), there will be no wildcard synthesis. There is no search + for an alternate. + + The important concept is that for any given lookup process, there + is at most one place at which wildcard synthetic records can be + obtained. If the source of synthesis does not exist, the lookup + terminates, the lookup does not look for other wildcard records. + +3.3.2 Closest Encloser and Source of Synthesis Examples + + To illustrate, using the example zone in section 2.2.1 of this + document, the following chart shows QNAMEs and the closest + enclosers. + + QNAME Closest Encloser Source of Synthesis + host3.example. example. *.example. + _telnet._tcp.host1.example. _tcp.host1.example. no source + _telnet._tcp.host2.example. host2.example. no source + _telnet._tcp.host3.example. example. *.example. + _chat._udp.host3.example. example. *.example. + foobar.*.example. *.example. no source + + + + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 12] + +Internet-Draft dnsext-wcard January 9, 2006 + +3.3.3 Type Matching + + RFC 1034 concludes part 'c' with this: + +# If the "*" label does not exist, check whether the name +# we are looking for is the original QNAME in the query +# or a name we have followed due to a CNAME. If the name +# is original, set an authoritative name error in the +# response and exit. Otherwise just exit. +# +# If the "*" label does exist, match RRs at that node +# against QTYPE. If any match, copy them into the answer +# section, but set the owner of the RR to be QNAME, and +# not the node with the "*" label. Go to step 6. + + The final paragraph covers the role of the QTYPE in the lookup + process. + + Based on implementation feedback and similarities between step + 'a' and step 'c' a change to this passage has been made. + + The change is to add the following text to step 'c' prior to the + instructions to "go to step 6": + + If the data at the source of synthesis is a CNAME, and + QTYPE doesn't match CNAME, copy the CNAME RR into the + answer section of the response changing the owner name + to the QNAME, change QNAME to the canonical name in the + CNAME RR, and go back to step 1. + + This is essentially the same text in step a covering the + processing of CNAME RRSets. + +4. Considerations with Special Types + + Sections 2 and 3 of this document discuss wildcard synthesis + with respect to names in the domain tree and ignore the impact + of types. In this section, the implication of wildcards of + specific types are discussed. The types covered are those + that have proven to be the most difficult to understand. The + types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and + "none," i.e., empty non-terminal wild card domain names. + +4.1 SOA RRSet at a Wild Card Domain Name + + A wild card domain name owning an SOA RRSet means that the + domain is at the root of the zone (apex). The domain can not + be a source of synthesis because that is, by definition, a + descendent node (of the closest encloser) and a zone apex is + at the top of the zone. + + +DNSEXT Working Group Expires July 9, 2006 [Page 13] + +Internet-Draft dnsext-wcard January 9, 2006 + + Although a wild card domain name owning an SOA RRSet can never + be a source of synthesis, there is no reason to forbid the + ownership of an SOA RRSet. + + E.g., given this zone: + $ORIGIN *.example. + @ 3600 IN SOA <SOA RDATA> + 3600 NS ns1.example.com. + 3600 NS ns1.example.net. + www 3600 TXT "the www txt record" + + A query for www.*.example.'s TXT record would still find the + "the www txt record" answer. The asterisk label only becomes + significant when section 4.3.2, step 3 part 'c' is in effect. + + Of course, there would need to be a delegation in the parent + zone, "example." for this to work too. This is covered in the + next section. + +4.2 NS RRSet at a Wild Card Domain Name + + With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now + in place, the semantics of a wild card domain name owning an + NS RRSet has come to be poorly defined. The dilemma relates to + a conflict between the rules for synthesis in part 'c' and the + fact that the resulting synthesis generates a record for which + the zone is not authoritative. In a DNSSEC signed zone, the + mechanics of signature management (generation and inclusion + in a message) have become unclear. + + Salient points of the working group discussion on this topic is + summarized in section 4.2.1. + + As a result of these discussion, there is no definition given for + wild card domain names owning an NS RRSet. The semantics are + left undefined until there is a clear need to have a set defined, + and until there is a clear direction to proceed. Operationally, + inclusion of wild card NS RRSets in a zone is discouraged, but + not barred. + +4.2.1 Discarded Notions + + Prior to DNSSEC, a wild card domain name owning a NS RRSet + appeared to be workable, and there are some instances in which + it is found in deployments using implementations that support + this. Continuing to allow this in the specification is not + tenable with DNSSEC. The reason is that the synthesis of the + NS RRSet is being done in a zone that has delegated away the + responsibility for the name. This "unauthorized" synthesis is + not a problem for the base DNS protocol, but DNSSEC, in affirming + the authorization model for DNS exposes the problem. + +DNSEXT Working Group Expires July 9, 2006 [Page 14] + +Internet-Draft dnsext-wcard January 9, 2006 + + Outright banning of wildcards of type NS is also untenable as + the DNS protocol does not define how to handle "illegal" data. + Implementations may choose not to load a zone, but there is no + protocol definition. The lack of the definition is complicated + by having to cover dynamic update [RFC 2136], zone transfers, + as well as loading at the master server. The case of a client + (resolver, caching server) getting a wildcard of type NS in + a reply would also have to be considered. + + Given the daunting challenge of a complete definition of how to + ban such records, dealing with existing implementations that + permit the records today is a further complication. There are + uses of wild card domain name owning NS RRSets. + + One compromise proposed would have redefined wildcards of type + NS to not be used in synthesis, this compromise fell apart + because it would have required significant edits to the DNSSEC + signing and validation work. (Again, DNSSEC catches + unauthorized data.) + + With no clear consensus forming on the solution to this dilemma, + and the realization that wildcards of type NS are a rarity in + operations, the best course of action is to leave this open-ended + until "it matters." + +4.3 CNAME RRSet at a Wild Card Domain Name + + The issue of a CNAME RRSet owned by a wild card domain name has + prompted a suggested change to the last paragraph of step 3c of + the algorithm in 4.3.2. The changed text appears in section + 3.3.3 of this document. + +4.4 DNAME RRSet at a Wild Card Domain Name + + Ownership of a DNAME [RFC2672] RRSet by a wild card domain name + represents a threat to the coherency of the DNS and is to be + avoided or outright rejected. Such a DNAME RRSet represents + non-deterministic synthesis of rules fed to different caches. + As caches are fed the different rules (in an unpredictable + manner) the caches will cease to be coherent. ("As caches + are fed" refers to the storage in a cache of records obtained + in responses by recursive or iterative servers.) + + For example, assume one cache, responding to a recursive + request, obtains the record: + "a.b.example. DNAME foo.bar.example.net." + and another cache obtains: + "b.example. DNAME foo.bar.example.net." + both generated from the record: + "*.example. DNAME foo.bar.example.net." + by an authoritative server. + +DNSEXT Working Group Expires July 9, 2006 [Page 15] + +Internet-Draft dnsext-wcard January 9, 2006 + + The DNAME specification is not clear on whether DNAME records + in a cache are used to rewrite queries. In some interpretations, + the rewrite occurs, in some, it is not. Allowing for the + occurrence of rewriting, queries for "sub.a.b.example. A" may + be rewritten as "sub.foo.bar.tld. A" by the former caching + server and may be rewritten as "sub.a.foo.bar.tld. A" by the + latter. Coherency is lost, an operational nightmare ensues. + + Another justification for banning or avoiding wildcard DNAME + records is the observation that such a record could synthesize + a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." + There is a restriction in the DNAME definition that no domain + exist below a DNAME-owning domain, hence, the wildcard DNAME + is not to be permitted. + +4.5 SRV RRSet at a Wild Card Domain Name + + The definition of the SRV RRset is RFC 2782 [RFC2782]. In the + definition of the record, there is some confusion over the term + "Name." The definition reads as follows: + +# The format of the SRV RR +... +# _Service._Proto.Name TTL Class SRV Priority Weight Port Target +... +# Name +# The domain this RR refers to. The SRV RR is unique in that the +# name one searches for is not this name; the example near the end +# shows this clearly. + + Do not confuse the definition "Name" with the owner name. I.e., + once removing the _Service and _Proto labels from the owner name + of the SRV RRSet, what remains could be a wild card domain name + but this is immaterial to the SRV RRSet. + + E.g., If an SRV record is: + _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. + + *.example is a wild card domain name and although it is the Name + of the SRV RR, it is not the owner (domain name). The owner + domain name is "_foo._udp.*.example." which is not a wild card + domain name. + + The confusion is likely based on the mixture of the specification + of the SRV RR and the description of a "use case." + +4.6 DS RRSet at a Wild Card Domain Name + + A DS RRSet owned by a wild card domain name is meaningless and + harmless. This statement is made in the context that an NS RRSet + at a wild card domain name is undefined. At a non-delegation + +DNSEXT Working Group Expires July 9, 2006 [Page 16] + +Internet-Draft dnsext-wcard January 9, 2006 + + point, a DS RRSet has no value (no corresponding DNSKEY RRSet + will be used in DNSSEC validation). If there is a synthesized + DS RRSet, it alone will not be very useful as it exists in the + context of a delegation point. + +4.7 NSEC RRSet at a Wild Card Domain Name + + Wild card domain names in DNSSEC signed zones will have an NSEC + RRSet. Synthesis of these records will only occur when the + query exactly matches the record. Synthesized NSEC RR's will not + be harmful as they will never be used in negative caching or to + generate a negative response. [RFC2308] + +4.8 RRSIG at a Wild Card Domain Name + + RRSIG records will be present at a wild card domain name in a + signed zone, and will be synthesized along with data sought in a + query. The fact that the owner name is synthesized is not a + problem as the label count in the RRSIG will instruct the + verifying code to ignore it. + +4.9 Empty Non-terminal Wild Card Domain Name + + If a source of synthesis is an empty non-terminal, then the + response will be one of no error in the return code and no RRSet + in the answer section. + +5. Security Considerations + + This document is refining the specifications to make it more + likely that security can be added to DNS. No functional + additions are being made, just refining what is considered + proper to allow the DNS, security of the DNS, and extending + the DNS to be more predictable. + +6. IANA Considerations + + None. + +7. References + + Normative References + + [RFC20] ASCII Format for Network Interchange, V.G. Cerf, + Oct-16-1969 + + [RFC1034] Domain Names - Concepts and Facilities, + P.V. Mockapetris, Nov-01-1987 + + [RFC1035] Domain Names - Implementation and Specification, P.V + Mockapetris, Nov-01-1987 + +DNSEXT Working Group Expires July 9, 2006 [Page 17] + +Internet-Draft dnsext-wcard January 9, 2006 + + [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 + + [RFC2119] Key Words for Use in RFCs to Indicate Requirement + Levels, S Bradner, March 1997 + + [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), + M. Andrews, March 1998 + + [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, + August 1999. + + [RFC2782] A DNS RR for specifying the location of services (DNS + SRV), A. Gulbrandsen, et.al., February 2000 + + [RFC4033] DNS Security Introduction and Requirements, R. Arends, + et.al., March 2005 + + [RFC4034] Resource Records for the DNS Security Extensions, + R. Arends, et.al., March 2005 + + [RFC4035] Protocol Modifications for the DNS Security Extensions, + R. Arends, et.al., March 2005 + + Informative References + + [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), + P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, + April 1997 + +8. Editor + + Name: Edward Lewis + Affiliation: NeuStar + Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US + Phone: +1-571-434-5468 + Email: ed.lewis@neustar.biz + + Comments on this document can be sent to the editor or the mailing + list for the DNSEXT WG, namedroppers@ops.ietf.org. + +9. Others Contributing to the Document + + This document represents the work of a large working group. The + editor merely recorded the collective wisdom of the working group. + + + + + + + + + +DNSEXT Working Group Expires July 9, 2006 [Page 17] + +Internet-Draft dnsext-wcard January 9, 2006 + +10. Trailing Boilerplate + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION + HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET + SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO + ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT + INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of + any Intellectual Property Rights or other rights that might + be claimed to pertain to the implementation or use of the + technology described in this document or the extent to which + any license under such rights might or might not be available; + nor does it represent that it has made any independent effort + to identify any such rights. Information on the procedures + with respect to rights in RFC documents can be found in BCP 78 + and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the + use of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR + repository at http://www.ietf.org/ipr. The IETF invites any + interested party to bring to its attention any copyrights, + patents or patent applications, or other proprietary rights + that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + +Expiration + + This document expires on or about July 9, 2006. + + + +DNSEXT Working Group Expires July 9, 2006 [Page 19] diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt new file mode 100644 index 0000000..0855ba3 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt @@ -0,0 +1,1232 @@ + + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: August 14, 2006 VeriSign + February 10, 2006 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-05 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 14, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This memo describes DNS iterative resolver behavior that results in a + significant query volume sent to the root and top-level domain (TLD) + name servers. We offer implementation advice to iterative resolver + developers to alleviate these unnecessary queries. The + recommendations made in this document are a direct byproduct of + observation and analysis of abnormal query traffic patterns seen at + two of the thirteen root name servers and all thirteen com/net TLD + name servers. + + + +Larson & Barber Expires August 14, 2006 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. A note about terminology in this memo . . . . . . . . . . 3 + 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5 + 2.1. Aggressive requerying for delegation information . . . . . 5 + 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7 + 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Inability to follow multiple levels of indirection . . . . 8 + 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9 + 2.4. Aggressive retransmission when fetching glue . . . . . . . 9 + 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10 + 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10 + 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11 + 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11 + 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12 + 2.7. Name server records with zero TTL . . . . . . . . . . . . 12 + 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13 + 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13 + 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 + 2.9. Queries for domain names resembling IPv4 addresses . . . . 14 + 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 + 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 + 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 + 2.11. Suboptimal name server selection algorithm . . . . . . . . 15 + 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 + 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 + 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 + 6. Internationalization considerations . . . . . . . . . . . . . 20 + 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question (<QNAME, QTYPE, QCLASS>) asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses (i.e., the + same query received simultaneously from multiple IP addresses). + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of indirection must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. None of the changes recommended affects the core DNS protocol + specification; instead, this document consists of guidelines to + implementors of iterative resolvers. + +1.1. A note about terminology in this memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and cause confusion resulting from + a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + to answer questions about certain zones authoritatively. This entity + is an iterative resolver combined with an authoritative name server + and is often called a "recursive name server" or a "caching name + server". + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + + + +Larson & Barber Expires August 14, 2006 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + because the focus is usually on that component. In instances where + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". As an example of the + difference, the name server component of a recursive name server + receives DNS queries and the iterative resolver component sends + queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address record" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +2. Observed iterative resolver misbehavior + +2.1. Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRset in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRset to one of the parent zone's name servers. (Note + that queries with QTYPE=NS are not required by the standard + resolution algorithm described in section 4.3.2 of RFC 1034 [2]. + These NS queries represent this implementation's addition to that + algorithm.) + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This implementation performs + this query to a zone's parent zone for each recursive query it + receives that fails because of a completely unresponsive set of name + servers for the target zone. Consider the effect when a popular zone + experiences a catastrophic failure of all its name servers: now every + recursive query for domain names in that zone sent to this recursive + name server implementation results in a query to the failed zone's + parent name servers. On one occasion when several dozen popular + zones became unreachable, the query load on the com/net name servers + increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent would be pointless: this query to the parent would come so + quickly on the heels of the referral that it would be almost certain + + + +Larson & Barber Expires August 14, 2006 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + to contain the same list of name servers. The chance of discovering + any new information is slim. + + The other possibility is that the iterative resolver successfully + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [3], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the TTL of the target + zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRset left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + + This section should not be understood to claim that all queries to a + zone's parent are bad. In some cases, such queries are not only + reasonable but required. Consider the situation when required + information, such as the address of a name server (i.e., the address + record corresponding to the RDATA of an NS record), has timed out of + an iterative resolver's cache before the corresponding NS record. If + the name of the name server is below the apex of the zone, then the + name server's address record is only available as glue in the parent + zone. For example, consider this NS record: + + example.com. IN NS ns.example.com. + + If a cache has this NS record but not the address record for + "ns.example.com", it is unable to contact the "example.com" zone + directly and must query the "com" zone to obtain the address record. + Note, however, that such a query would not have QTYPE=NS according to + the standard resolution algorithm. + +2.1.1. Recommendation + + An iterative resolver MUST NOT send a query for the NS RRset of a + non-responsive zone to any of the name servers for that zone's parent + + + +Larson & Barber Expires August 14, 2006 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRset: + + 1. is not authoritative for the zone (i.e., lame), or, + + 2. returns a server failure response (RCODE=2), or, + + 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. + +2.2. Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers + are unavailable or misconfigured. Different failure modes have + different expected durations. Some symptoms indicate problems that + are potentially transient; for example, various types of ICMP + unreachable messages because a name server process is not running or + a host or network is unreachable, or a complete lack of a response to + a query. Such responses could be the result of a host rebooting or + temporary outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + + It should also be noted, however, that some authoritative name server + implementations appear to be lame only for queries of certain types + as described in RFC 4074 [5]. In this case, it makes sense to retry + the "lame" servers for other types of queries, particularly when all + known authoritative name servers appear to be "lame". + +2.2.1. Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e. lame servers). + If this caching is performed, lame servers MUST be cached against the + specific query tuple <zone name, class, server IP address>. Zone + name can be derived from the owner name of the NS record that was + referenced to query the name server that was discovered to be lame. + + + +Larson & Barber Expires August 14, 2006 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers based on a time interval from + when the server is discovered to be lame. A minimum interval of + thirty minutes is RECOMMENDED. + + An exception to this recommendation occurs if all name servers for a + zone are marked lame. In that case, the iterative resolver SHOULD + temporarily ignore the servers' lameness status and query one or more + servers. This behavior is a workaround for the type-specific + lameness issue described in the previous section. + + Implementors should take care not to make lame server avoidance logic + overly broad: note that a name server could be lame for a parent zone + but not a child zone, e.g., lame for "example.com" but properly + authoritative for "sub.example.com". Therefore a name server should + not be automatically considered lame for subzones. In the case + above, even if a name server is known to be lame for "example.com", + it should be queried for QNAMEs at or below "sub.example.com" if an + NS record indicates it should be authoritative for that zone. + +2.3. Inability to follow multiple levels of indirection + + Some iterative resolver implementations are unable to follow + sufficient levels of indirection. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in existing gTLDs, increasing the + number of delegations using out-of-zone name servers. + + + + + + +Larson & Barber Expires August 14, 2006 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +2.3.1. Recommendation + + Clearly constructing a delegation that relies on multiple levels of + indirection is not a good administrative practice. However, the + practice is widespread enough to require that iterative resolvers be + able to cope with it. Iterative resolvers SHOULD be able to handle + arbitrary levels of indirection resulting from out-of-zone name + servers. Iterative resolvers SHOULD implement a level-of-effort + counter to avoid loops or otherwise performing too much work in + resolving pathological cases. + + A best practice that avoids this entire issue of indirection is to + name one or more of a zone's name servers in the zone itself. For + example, if the zone is named "example.com", consider naming some of + the name servers "ns{1,2,...}.example.com" (or similar). + +2.4. Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers non- + recursive queries from iterative resolvers looking for information in + zones it serves. With glue fetching enabled, however, an + authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a glue- + fetching name server can send queries that reach other name servers, + but is apparently prevented from receiving the responses. For + example, perhaps the name server is authoritative-only and therefore + its administrators expect it to receive only queries and not + responses. Perhaps unaware of glue fetching and presuming that the + name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + + + +Larson & Barber Expires August 14, 2006 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + prevents it from receiving responses. If this is the case, all glue- + fetching queries will go answered. + + We have observed name server implementations whose iterative + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1. Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5. Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it can't respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + + + +Larson & Barber Expires August 14, 2006 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + servers, which could explain how such a situation could persist + without being detected. + +2.5.1. Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries to pass through but not the resulting replies. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6. Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRset from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4 of RFC 2181 [3], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a non- + authoritative answer. Thus the "example.com" NS RRset just received + from the "example.com" authoritative server overrides the + "example.com" NS RRset received moments ago from the "com" + + + +Larson & Barber Expires August 14, 2006 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in address + record queries to the "com" authoritative servers. Queries for such + obviously bogus glue address records occur frequently at the com/net + name servers. + +2.6.1. Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the apex of the zone the + NS record appears in. Note that further levels of delegation are + possible, so a missing trailing dot could inadvertently create a name + server name that actually exists in a subzone. + + An authoritative name server SHOULD issue a warning when one of a + zone's NS records references a name server below the zone's apex when + a corresponding address record does not exist in the zone AND there + are no delegated subzones where the address record could exist. + +2.7. Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + + + +Larson & Barber Expires August 14, 2006 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want iterative resolvers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + +2.7.1. Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone. + +2.8. Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + "internal root" design, there could conceivably be private, non- + + + +Larson & Barber Expires August 14, 2006 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + public TLD or root zones that would be the appropriate targets for a + dynamic update. + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining closest enclosing zones for future updates. Once + the closest enclosing zone is determined with this method, the update + will either succeed or fail and there is no need to send further + updates to higher-level zones. The important point is that walking + up the tree with queries yields cacheable information, whereas + walking up the tree by sending UPDATE messages does not. + +2.8.1. Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level names to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9. Queries for domain names resembling IPv4 addresses + + The root name servers receive a significant number of A record + queries where the QNAME looks like an IPv4 address. The source of + these queries is unknown. It could be attributed to situations where + a user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1. Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + + + +Larson & Barber Expires August 14, 2006 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + bandwidth. A possible solution is to delegate these numeric TLDs + from the root zone to a separate set of servers to absorb the + traffic. The "black hole servers" used by the AS 112 Project [8], + which are currently delegated the in-addr.arpa zones corresponding to + RFC 1918 [7] private use address space, would be a possible choice to + receive these delegations. Of course, the proper and usual root zone + change procedures would have to be followed to make such a change to + the root zone. + +2.10. Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offers recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use + name servers that do not offer recursion, but we are not aware of any + stub resolver implementation that offers any feedback to the user + when so configured, aside from simply "not working". + +2.10.1. Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be immediately notified if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11. Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under specified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + + +Larson & Barber Expires August 14, 2006 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1. Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + + o Do not make assumptions based on NS RRset order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for "a.gtld- + servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other 12 authoritative servers for "com".) + + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +3. Acknowledgments + + The authors would like to thank the following people for their + comments that improved this document: Andras Salamon, Dave Meyer, + Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, + Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We + apologize if we have omitted anyone; any oversight was unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +4. IANA considerations + + There are no new IANA considerations introduced by this memo. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +5. Security considerations + + The iterative resolver misbehavior discussed in this document exposes + the root and TLD name servers to increased risk of both intentional + and unintentional denial of service attacks. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +6. Internationalization considerations + + There are no new internationalization considerations introduced by + this memo. + +7. Informative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS + Queries for IPv6 Addresses", RFC 4074, May 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, + RFC 1918, February 1996. + + [8] <http://www.as112.net> + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 14, 2006 [Page 20] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +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 14, 2006 [Page 21] + +Internet-Draft Observed DNS Resolution Misbehavior February 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Larson & Barber Expires August 14, 2006 [Page 22] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt new file mode 100644 index 0000000..8ca68a8 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt @@ -0,0 +1,2016 @@ + + + +DNSOP O. Kolkman +Internet-Draft R. Gieben +Obsoletes: 2541 (if approved) NLnet Labs +Expires: September 7, 2006 March 6, 2006 + + + DNSSEC Operational Practices + draft-ietf-dnsop-dnssec-operational-practices-08.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on September 7, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a set of practices for operating the DNS with + security extensions (DNSSEC). The target audience is zone + administrators deploying DNSSEC. + + The document discusses operational aspects of using keys and + signatures in the DNS. It discusses issues as key generation, key + storage, signature generation, key rollover and related policies. + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 1] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + This document obsoletes RFC 2541, as it covers more operational + ground and gives more up to date requirements with respect to key + sizes and the new DNSSEC specification. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 4 + 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 + 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 + 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 + 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 + 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7 + 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 8 + 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9 + 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9 + 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 12 + 4. Signature generation, Key Rollover and Related Policies . . . 12 + 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13 + 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15 + 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19 + 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 20 + 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 21 + 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 22 + 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 22 + 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24 + 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 24 + 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 24 + 4.4.1. Initial Key Exchanges and Parental Policies + Considerations . . . . . . . . . . . . . . . . . . . . 24 + 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 25 + 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 25 + 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 26 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 + Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 29 + Appendix B. Zone Signing Key Rollover Howto . . . . . . . . . . . 30 + Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 31 + Appendix D. Document Details and Changes . . . . . . . . . . . . 33 + + + +Kolkman & Gieben Expires September 7, 2006 [Page 2] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33 + D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33 + D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33 + D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33 + D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34 + D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34 + D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34 + D.8. draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34 + D.9. draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 + Intellectual Property and Copyright Statements . . . . . . . . . . 36 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 3] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +1. Introduction + + This document describes how to run a DNSSEC (DNS SECure) enabled + environment. It is intended for operators who have knowledge of the + DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC. See + RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the + newly introduced Resource Records and finally RFC 4035 [6] for the + protocol changes. + + During workshops and early operational deployment tests, operators + and system administrators have gained experience about operating the + DNS with security extensions (DNSSEC). This document translates + these experiences into a set of practices for zone administrators. + At the time of writing, there exists very little experience with + DNSSEC in production environments; this document should therefore + explicitly not be seen as representing 'Best Current Practices'. + + The procedures herein are focused on the maintenance of signed zones + (i.e. signing and publishing zones on authoritative servers). It is + intended that maintenance of zones such as re-signing or key + rollovers be transparent to any verifying clients on the Internet. + + The structure of this document is as follows. In Section 2 we + discuss the importance of keeping the "chain of trust" intact. + Aspects of key generation and storage of private keys are discussed + in Section 3; the focus in this section is mainly on the private part + of the key(s). Section 4 describes considerations concerning the + public part of the keys. Since these public keys appear in the DNS + one has to take into account all kinds of timing issues, which are + discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the + rollover, or supercession, of keys. Finally Section 4.4 discusses + considerations on how parents deal with their children's public keys + in order to maintain chains of trust. + + The typographic conventions used in this document are explained in + Appendix C. + + Since this is a document with operational suggestions and there are + no protocol specifications, the RFC 2119 [9] language does not apply. + + This document obsoletes RFC 2541 [12]. + +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 + [18]). Therefore, this document will use the term 'key' rather + loosely. Where it is written that 'a key is used to sign data' it is + + + +Kolkman & Gieben Expires September 7, 2006 [Page 4] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + assumed that the reader understands that it is the private part of + the key pair that is used for signing. It is also assumed that the + reader understands that the public part of the key pair is published + in the DNSKEY resource record and that it is the public part that is + used in key exchanges. + +1.2. Time Definitions + + In this document we will be using a number of time related terms. + The following definitions apply: + o "Signature validity period" + The period that a signature is valid. It starts at the time + specified in the signature inception field of the RRSIG RR and + ends at the time specified in the expiration field of the RRSIG + RR. + o "Signature publication period" + Time after which a signature (made with a specific key) is + replaced with a new signature (made with the same key). This + replacement takes place by publishing the relevant RRSIG in the + master zone file. + After one stops publishing an RRSIG in a zone it may take a + while before the RRSIG has expired from caches and has actually + been removed from the DNS. + o "Key effectivity period" + The period during which a key pair is expected to be effective. + This period is defined as the time between the first inception + time stamp and the last expiration date of any signature made + with this key, regardless of any discontinuity in the use of + the key. + The key effectivity period can span multiple signature validity + periods. + o "Maximum/Minimum Zone Time to Live (TTL)" + The maximum or minimum value of the TTLs from the complete set + of RRs in a zone. Note that the minimum TTL is not the same as + the MINIMUM field in the SOA RR. See [11] for more + information. + + +2. Keeping the Chain of Trust Intact + + Maintaining a valid chain of trust is important because broken chains + of trust will result in data being marked as Bogus (as defined in [4] + section 5), which may cause entire (sub)domains to become invisible + to verifying clients. The administrators of secured zones have to + realize that their zone is, to verifying clients, part of a chain of + trust. + + As mentioned in the introduction, the procedures herein are intended + + + +Kolkman & Gieben Expires September 7, 2006 [Page 5] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + to ensure that maintenance of zones, such as re-signing or key + rollovers, will be transparent to the verifying clients on the + Internet. + + Administrators of secured zones will have to keep in mind that data + published on an authoritative primary server will not be immediately + seen by verifying clients; it may take some time for the data to be + transferred to other secondary authoritative nameservers and clients + may be fetching data from caching non-authoritative servers. In this + light it is good to note that the time for a zone transfer from + master to slave is negligible when using NOTIFY [8] and IXFR [7], + increasing by reliance on AXFR, and more if you rely on the SOA + timing parameters for zone refresh. + + 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 replacing the compromised keys + as soon as possible must be made. Then zone administrators will have + to make a trade off, between keeping the chain of trust intact - + thereby allowing for attacks with the compromised key - or to + deliberately break the chain of trust and making secured sub domains + invisible to security aware resolvers. Also see Section 4.3. + + +3. Keys Generation and Storage + + This section describes a number of considerations with respect to the + security of keys. It deals with the generation, effectivity period, + size and storage of private keys. + +3.1. Zone and Key Signing Keys + + The DNSSEC validation protocol does not distinguish between different + types of DNSKEYs. All DNSKEYs can be used during the validation. In + practice operators use Key Signing and Zone Signing Keys and use the + so-called (Secure Entry Point) SEP [3] flag to distinguish between + them during operations. The dynamics and considerations are + discussed below. + + To make zone re-signing and key rollover procedures easier to + + + +Kolkman & Gieben Expires September 7, 2006 [Page 6] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + implement, it is possible to use one or more keys as Key Signing Keys + (KSK). These keys will only sign the apex DNSKEY RRSet in a zone. + Other keys can be used to sign all the RRSets in a zone and are + referred to as Zone Signing Keys (ZSK). In this document we assume + that KSKs are the subset of keys that are used for key exchanges with + the parent and potentially for configuration as trusted anchors - the + SEP keys. In this document we assume a one-to-one mapping between + KSK and SEP keys and we assume the SEP flag to be set on all KSKs. + +3.1.1. Motivations for the KSK and ZSK Separation + + Differentiating between the KSK and ZSK functions has several + advantages: + + o No parent/child interaction is required when ZSKs are updated. + o The KSK can be made stronger (i.e. using more bits in the key + material). This has little operational impact since it is only + used to sign a small fraction of the zone data. Also the KSK is + only used to verify the zone's key set, not for other RRSets in + the zone. + o As the KSK is only used to sign a key set, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from and in a safer location than the ZSK. + o A KSK can have a longer key effectivity period. + + For almost any method of key management and zone signing the KSK is + used less frequently than the ZSK. Once a key set is signed with the + KSK all the keys in the key set can be used as ZSK. If a ZSK is + compromised, it can be simply dropped from the key set. The new key + set is then re-signed with the KSK. + + Given the assumption that for KSKs the SEP flag is set, the KSK can + be distinguished from a ZSK by examining the flag field in the DNSKEY + RR. If the flag field is an odd number it is a KSK. If it is an + even number it is a ZSK. + + The zone signing key can be used to sign all the data in a zone on a + regular basis. When a zone signing key is to be rolled, no + interaction with the parent is needed. This allows for "Signature + Validity Periods" on the order of days. + + The key signing key is only to be used to sign the DNSKEY RRs in a + zone. If a key signing key is to be rolled over, there will be + interactions with parties other than the zone administrator. These + can include the registry of the parent zone or administrators of + verifying resolvers that have the particular key configured as secure + entry points. Hence, the key effectivity period of these keys can + and should be made much longer. Although, given a long enough key, + + + +Kolkman & Gieben Expires September 7, 2006 [Page 7] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + the Key Effectivity Period can be on the order of years we suggest + planning for a key effectivity of the order of a few months so that a + key rollover remains an operational routine. + +3.1.2. KSKs for High Level Zones + + Higher level zones are generally more sensitive than lower level + zones. Anyone controlling or breaking the security of a zone thereby + obtains authority over all of its sub domains (except in the case of + resolvers that have locally configured the public key of a sub + domain, in which case this, and only this, sub domain wouldn't be + affected by the compromise of the parent zone). Therefore, extra + care should be taken with high level zones and strong keys should + used. + + The root zone is the most critical of all zones. Someone controlling + or compromising the security of the root zone would control the + entire DNS name space of all resolvers using that root zone (except + in the case of resolvers that have locally configured the public key + of a sub domain). Therefore, the utmost care must be taken in the + securing of the root zone. The strongest and most carefully handled + keys should be used. The root zone private key should always be kept + off line. + + Many resolvers will start at a root server for their access to and + authentication of DNS data. Securely updating the trust anchors in + an enormous population of resolvers around the world will be + extremely difficult. + +3.2. Key Generation + + Careful generation of all keys is a sometimes overlooked but + absolutely essential element in any cryptographically secure system. + The strongest algorithms used with the longest keys are still of no + use if an adversary can guess enough to lower the size of the likely + key space so that it can be exhaustively searched. Technical + suggestions for the generation of random keys will be found in RFC + 4086 [15]. One should carefully assess if the random number + generator used during key generation adheres to these suggestions. + + Keys with a long effectivity period are particularly sensitive as + they will represent a more valuable target and be subject to attack + for a longer time than short period keys. It is strongly recommended + that long term key generation occur off-line in a manner isolated + from the network via an air gap or, at a minimum, high level secure + hardware. + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 8] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +3.3. Key Effectivity Period + + For various reasons keys in DNSSEC need to be changed once in a + while. The longer a key is in use, the greater the probability that + it will have been compromised through carelessness, accident, + espionage, or cryptanalysis. Furthermore when key rollovers are too + rare an event, they will not become part of the operational habit and + there is risk that nobody on-site will remember the procedure for + rollover when the need is there. + + From a purely operational perspective a reasonable key effectivity + period for Key Signing Keys is 13 months, with the intent to replace + them after 12 months. An intended key effectivity period of a month + is reasonable for Zone Signing Keys. + + For key sizes that matches these effectivity periods see Section 3.5. + + As argued in Section 3.1.2 securely updating trust anchors will be + extremely difficult. On the other hand the "operational habit" + argument does also apply to trust anchor reconfiguration. If a short + key-effectivity period is used and the trust anchor configuration has + to be revisited on a regular basis the odds that the configuration + tends to be forgotten is smaller. The trade-off is against a system + that is so dynamic that administrators of the validating clients will + not be able to follow the modifications. + + Key effectivity periods can be made very short, as in the order of a + few minutes. But when replacing keys one has to take the + considerations from Section 4.1 and Section 4.2 into account. + +3.4. Key Algorithm + + There are currently three different types of algorithms that can be + used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter + is fairly new and has yet to be standardized for usage in DNSSEC. + + RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2000, its use is now also free. + + DSA has been developed by NIST. The creation of signatures takes + roughly the same time as with RSA, but is 10 to 40 times as slow for + verification [18]. + + We suggest the use of RSA/SHA-1 as the preferred algorithm for the + key. The current known attacks on RSA can be defeated by making your + key longer. As the MD5 hashing algorithm is showing (theoretical) + cracks, we recommend the usage of SHA-1. + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 9] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + At the time of publication it is known that the SHA-1 hash has + cryptanalysis issues. There is work in progress on addressing these + issues. We recommend the use of public key algorithms based on + hashes stronger than SHA-1, e.g. SHA-256, as soon as these + algorithms are available in protocol specifications (See [20] and + [21] ) and implementations. + +3.5. Key Sizes + + When choosing key sizes, zone administrators will need to take into + account how long a key will be used, how much data will be signed + during the key publication period (See Section 8.10 of [18]) and, + optionally, how large the key size of the parent is. As the chain of + trust really is "a chain", there is not much sense in making one of + the keys in the chain several times larger then the others. As + always, it's the weakest link that defines the strength of the entire + chain. Also see Section 3.1.1 for a discussion of how keys serving + different roles (ZSK v. KSK) may need different key sizes. + + Generating a key of the correct size is a difficult problem, RFC 3766 + [14] tries to deal with that problem. The first part of the + selection procedure in Section 1 of the RFC states: + + 1. Determine the attack resistance necessary to satisfy the + security requirements of the application. Do this by + estimating the minimum number of computer operations that + the attacker will be forced to do in order to compromise + the security of the system and then take the logarithm base + two of that number. Call that logarithm value "n". + + A 1996 report recommended 90 bits as a good all-around choice + for system security. The 90 bit number should be increased + by about 2/3 bit/year, or about 96 bits in 2005. + + [14] goes on to explain how this number "n" can be used to calculate + the key sizes in public key cryptography. This culminated in the + table given below (slightly modified for our purpose): + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 10] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + +-------------+-----------+--------------+ + | System | | | + | requirement | Symmetric | RSA or DSA | + | for attack | key size | modulus size | + | resistance | (bits) | (bits) | + | (bits) | | | + +-------------+-----------+--------------+ + | 70 | 70 | 947 | + | 80 | 80 | 1228 | + | 90 | 90 | 1553 | + | 100 | 100 | 1926 | + | 150 | 150 | 4575 | + | 200 | 200 | 8719 | + | 250 | 250 | 14596 | + +-------------+-----------+--------------+ + + The key sizes given are rather large. This is because these keys are + resilient against a trillionaire attacker. Assuming this rich + attacker will not attack your key and that the key is rolled over + once a year, we come to the following recommendations about KSK + sizes; 1024 bits low value domains, 1300 for medium value and 2048 + for the high value domains. + + Whether a domain is of low, medium, high value depends solely on the + views of the zone owner. One could for instance view leaf nodes in + the DNS as of low value and TLDs or the root zone of high value. The + suggested key sizes should be safe for the next 5 years. + + As ZSKs can be rolled over more easily (and thus more often) the key + sizes can be made smaller. But as said in the introduction of this + paragraph, making the ZSKs' key sizes too small (in relation to the + KSKs' sizes) doesn't make much sense. Try to limit the difference in + size to about 100 bits. + + Note that nobody can see into the future, and that these key sizes + are only provided here as a guide. Further information can be found + in [17] and Section 7.5 of [18]. It should be noted though that [17] + is already considered overly optimistic about what key sizes are + considered safe. + + One final note concerning key sizes. Larger keys will increase the + sizes of the RRSIG and DNSKEY records and will therefore increase the + chance of DNS UDP packet overflow. Also the time it takes to + validate and create RRSIGs increases with larger keys, so don't + needlessly double your key sizes. + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 11] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +3.6. Private Key Storage + + It is recommended that, where possible, zone private keys and the + zone file master copy that is to be signed, be kept and used in off- + line, non-network connected, physically secure machines only. + Periodically an application can be run to add authentication to a + zone by adding RRSIG and NSEC RRs. Then the augmented file can be + transferred. + + When relying on dynamic update to manage a signed zone [10], be aware + that at least one private key of the zone will have to reside on the + master server. This key is only as secure as the amount of exposure + the server receives to unknown clients and the security of the host. + Although not mandatory one could administer the DNS in the following + way. The master that processes the dynamic updates is unavailable + from generic hosts on the Internet, it is not listed in the NS RR + set, although its name appears in the SOA RRs MNAME field. The + nameservers in the NS RR set are able to receive zone updates through + NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism. This + approach is known as the "hidden master" setup. + + The ideal situation is to have a one way information flow to the + network to avoid the possibility of tampering from the network. + Keeping the zone master file on-line on the network and simply + cycling it through an off-line signer does not do this. The on-line + version could still be tampered with if the host it resides on is + compromised. For maximum security, the master copy of the zone file + should be off net and should not be updated based on an unsecured + network mediated communication. + + In general keeping a zone-file off-line will not be practical and the + machines on which zone files are maintained will be connected to a + network. Operators are advised to take security measures to shield + unauthorized access to the master copy. + + For dynamically updated secured zones [10] both the master copy and + the private key that is used to update signatures on updated RRs will + need to be on-line. + + +4. Signature generation, Key Rollover and Related Policies + +4.1. Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA fields + REFRESH, RETRY and EXPIRATION are timers used to determine the time + elapsed after a slave server synchronized with a master server. The + Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] + + + +Kolkman & Gieben Expires September 7, 2006 [Page 12] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + are used to determine how long a forwarder should cache data after it + has been fetched from an authoritative server. By using a signature + validity period, DNSSEC introduces the notion of an absolute time in + the DNS. Signatures in DNSSEC have an expiration date after which + the signature is marked as invalid and the signed data is to be + considered Bogus. + +4.1.1. Time Considerations + + Because of the expiration of signatures, one should consider the + following: + o We suggest the Maximum Zone TTL of your zone data to be a fraction + of your signature validity period. + If the TTL would be of similar order as the signature validity + period, then all RRSets fetched during the validity period + would be cached until the signature expiration time. Section + 7.1 of [4] suggests that "the resolver may use the time + remaining before expiration of the signature validity period of + a signed RRSet as an upper bound for the TTL". As a result + query load on authoritative servers would peak at signature + expiration time, as this is also the time at which records + simultaneously expire from caches. + To avoid query load peaks we suggest the TTL on all the RRs in + your zone to be at least a few times smaller than your + signature validity period. + o We suggest the Signature Publication Period to end at least one + Maximum Zone TTL duration before the end of the Signature Validity + Period. + Re-signing a zone shortly before the end of the signature + validity period may cause simultaneous expiration of data from + caches. This in turn may lead to peaks in the load on + authoritative servers. + o We suggest the minimum zone TTL to be long enough to both fetch + and verify all the RRs in the trust chain. In workshop + environments it has been demonstrated [19] that a low TTL (under 5 + to 10 minutes) caused disruptions because of the following two + problems: + 1. During validation, some data may expire before the + validation is complete. The validator should be able to keep + all data, until is completed. This applies to all RRs needed + to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the + final answers i.e. the RRSet 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 September 7, 2006 [Page 13] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + o Slave servers will need to be able to fetch newly signed zones + well before the RRSIGs in the zone served by the slave server pass + their signature expiration time. + When a slave server is out of sync with its master and data in + a zone is signed by expired signatures it may be better for the + slave server not to give out any answer. + Normally a slave server that is not able to contact a master + server for an extended period will expire a zone. When that + happens the server will respond differently to queries for that + zone. Some servers issue SERVFAIL while others turn off the + 'AA' bit in the answers. The time of expiration is set in the + SOA record and is relative to the last successful refresh + between the master and the slave server. There exists no + coupling between the signature expiration of RRSIGs in the zone + and the expire parameter in the SOA. + If the server serves a DNSSEC zone then 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 shorter than the signature validity period. + The consequence of an authoritative server not being able to + update a zone, whilst that zone includes expired signatures, is + that non-secure resolvers will continue to be able to resolve + data served by the particular slave servers while security + aware resolvers will experience problems because of answers + being marked as Bogus. + 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 times out. + We also suggest that operators of nameservers that supply + secondary services develop 'watch dogs' to spot upcoming + signature expirations in zones they slave, and take appropriate + action. + When determining the value for the expiration parameter one has + to take the following into account: What are the chances that + all my secondaries expire the zone; How quickly can I reach an + administrator of secondary servers to load a valid zone? All + these arguments are not DNSSEC specific but may influence the + choice of your signature validity intervals. + +4.2. Key Rollovers + + A DNSSEC key cannot be used forever (see Section 3.3). So key + rollovers -- or supercessions, as they are sometimes called -- are a + fact of life when using DNSSEC. Zone administrators who are in the + process of rolling their keys have to take into account that data + + + +Kolkman & Gieben Expires September 7, 2006 [Page 14] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + 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 occurs when zone material signed + with an old key is being validated by a resolver which does not have + the old zone key cached. If the old key is no longer present in the + current zone, this validation fails, marking the data Bogus. + Alternatively, an attempt could be made to validate data which is + signed with a new key against an old key that lives in a local cache, + also resulting in data being marked Bogus. + +4.2.1. Zone Signing Key Rollovers + + For zone signing key rollovers there are two ways to make sure that + during the rollover data still cached can be verified with the new + key sets or newly generated signatures can be verified with the keys + still in caches. One schema, described in Section 4.2.1.2, uses + double signatures; the other uses key pre-publication + (Section 4.2.1.1). The pros, cons and recommendations are described + in Section 4.2.1.3. + +4.2.1.1. Pre-publish Key Rollover + + This section shows how to perform a ZSK rollover without the need to + sign all the data in a zone twice - the so-called "pre-publish + rollover".This method has advantages in the case of a key compromise. + If the old key is compromised, the new key has already been + distributed in the DNS. The zone administrator is then able to + quickly switch to the new key and remove the compromised key from the + zone. Another major advantage is that the zone size does not double, + as is the case with the double signature ZSK rollover. A small + "HOWTO" for this kind of rollover can be found in Appendix B. + + Pre-publish Key Rollover involves four stages as follows: + + initial new DNSKEY new RRSIGs DNSKEY removal + + 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) + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 15] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + initial: Initial version 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. + new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no + signatures are generated with this key yet, but this does not + secure against brute force attacks on the public key. The minimum + duration of this pre-roll phase is the time it takes for the data + to propagate to the authoritative servers plus TTL value of the + key set. + new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is + used to sign the data in the zone exclusively (i.e. all the + signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 + remains published in the key set. This way data that was loaded + into caches from version 1 of the zone can still be verified with + key sets fetched from version 2 of the zone. + The minimum time that the key set including DNSKEY 10 is to be + published is the time that it takes for zone data from the + previous version of the zone to expire from old caches i.e. the + time it takes for this zone to propagate to all authoritative + servers plus the Maximum Zone TTL value of any of the data in the + previous version of the zone. + DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now + only containing DNSKEY 1 and DNSKEY 11 is re-signed 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 "new DNSKEY" + as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY + (II)": + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 16] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + initial new RRSIGs new DNSKEY + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 DNSKEY12 + RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + + + new RRSIGs (II) new DNSKEY (II) + + SOA3 SOA4 + RRSIG12(SOA3) RRSIG12(SOA4) + + DNSKEY1 DNSKEY1 + DNSKEY11 DNSKEY12 + DNSKEY12 DNSKEY13 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG12(DNSKEY) RRSIG12(DNSKEY) + + + Pre-Publish Key Rollover, showing two rollovers. + + Note that the key introduced in the "new DNSKEY" phase is not used + for production yet; the private key can thus be stored in a + physically secure manner and does not need to be 'fetched' every time + a zone needs to be signed. + +4.2.1.2. Double Signature Zone Signing Key Rollover + + This section shows how to perform a ZSK key rollover using the double + zone data signature scheme, aptly named "double sig rollover". + + During the "new DNSKEY" stage the new version of the zone file will + need to propagate to all authoritative servers and the data that + exists in (distant) caches will need to expire, requiring at least + the maximum Zone TTL. + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 17] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + Double Signature Zone Signing Key Rollover involves three stages as + follows: + + initial new DNSKEY DNSKEY removal + + 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) + + initial: Initial Version 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. + new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is + introduced into the key set and all the data in the zone is signed + with DNSKEY 10 and DNSKEY 11. The rollover period will need to + continue 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. + DNSKEY removal: DNSKEY 10 is removed from the zone. All the + signatures from DNSKEY 10 are removed from the zone. The key set, + now only containing DNSKEY 11, is re-signed with DNSKEY 1. + + At every instance, RRSIGs from the previous version of the zone can + be verified with the DNSKEY RRSet from the current version and the + other way around. The data from the current version can be verified + with the data from the previous version of the zone. The duration of + the "new DNSKEY" phase and the period between rollovers should be at + least the Maximum Zone TTL. + + Making sure that the "new DNSKEY" phase lasts until the signature + expiration time of the data in initial version of the zone is + recommended. This way all caches are cleared of the old signatures. + However, this duration 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. + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 18] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +4.2.1.3. Pros and Cons of the Schemes + + Pre-publish Key Rollover: This rollover does not involve signing the + zone data twice. Instead, before the actual rollover, the new key + is published in the key set and thus available for cryptanalysis + attacks. A small disadvantage is that this process requires four + steps. Also the pre-publish scheme involves more parental work + when used for KSK rollovers as explained in Section 4.2.3. + Double Signature Zone-signing Key Rollover: The drawback of this + signing scheme is that during the rollover the number of + signatures in your zone doubles, this may be prohibitive if you + have very big zones. An advantage is that it only requires three + steps. + +4.2.2. Key Signing Key Rollovers + + For the rollover of a key signing key the same considerations as for + the rollover of a zone signing key apply. However we can use a + double signature scheme to guarantee that old data (only the apex key + set) in caches can be verified with a new key set and vice versa. + Since only the key set is signed with a KSK, zone size considerations + do not apply. + + + initial new DNSKEY DS change DNSKEY removal + Parent: + SOA0 --------> SOA1 --------> + RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> + DS1 --------> DS2 --------> + RRSIGpar(DS) --------> RRSIGpar(DS) --------> + + + Child: + 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) + + Stages of Deployment for Key Signing Key Rollover. + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 19] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + initial: Initial version 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. + new DNSKEY: During the "new DNSKEY" phase the zone administrator + generates a second KSK, DNSKEY2. The key is provided to the + parent and the child will have to wait until a new DS RR has been + generated that points to DNSKEY2. After that DS RR has been + published on all servers authoritative for the parent's zone, the + zone administrator has to wait at least TTL_DS to make sure that + the old DS RR has expired from caches. + DS change: The parent replaces DS1 with DS2. + DNSKEY removal: DNSKEY1 has been removed. + + The scenario above puts the responsibility for maintaining a valid + chain of trust with the child. It also is based on the premises that + the parent only has one DS RR (per algorithm) per zone. An + alternative mechanism has been considered. Using an established + trust relation, the interaction can be performed in-band, and the + removal of the keys by the child can possibly be signaled by the + parent. In this mechanism there are periods where there are two DS + RRs at the parent. Since at the moment of writing the protocol for + this interaction has not been developed, further discussion is out of + scope for this document. + +4.2.3. Difference Between ZSK and KSK Rollovers + + Note that KSK rollovers and ZSK rollovers are different in the sense + that a KSK rollover requires interaction with the parent (and + possibly replacing of trust anchors) and the ensuing delay while + waiting for it. + + A zone key rollover can be handled in two different ways: pre-publish + (Section Section 4.2.1.1) and double signature (Section + Section 4.2.1.2). + + As the KSK is used to validate the key set and because the KSK is not + changed during a ZSK rollover, a cache is able to validate the new + key set of the zone. The pre-publish method would also work for a + KSK rollover. The records that are to be pre-published are the + parental DS RRs. The pre-publish method has some drawbacks for KSKs. + We first describe the rollover scheme and then indicate these + drawbacks. + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 20] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + initial new DS new DNSKEY DS/DNSKEY removal + Parent: + SOA0 SOA1 --------> SOA2 + RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) + DS1 DS1 --------> DS2 + DS2 --------> + RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) + + + + Child: + SOA0 --------> SOA1 SOA1 + RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) + --------> + DNSKEY1 --------> DNSKEY2 DNSKEY2 + --------> + DNSKEY10 --------> DNSKEY10 DNSKEY10 + RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) + + Stages of Deployment for a Pre-publish Key Signing Key rollover. + + When the child zone wants to roll it notifies the parent during the + "new DS" phase and submits the new key (or the corresponding DS) to + the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 + and DNSKEY2 respectively. During the rollover ("new DNSKEY" phase), + which can take place as soon as the new DS set propagated through the + DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that + ("DS/DNSKEY removal" phase) it can notify the parent that the old DS + record can be deleted. + + The drawbacks of this scheme are that during the "new DS" phase the + parent cannot verify the match between the DS2 RR and DNSKEY2 using + the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a + "security lame" key (See Section 4.4.3). Finally the child-parent + interaction consists of two steps. The "double signature" method + only needs one interaction. + +4.2.4. Automated Key Rollovers + + As keys must be renewed periodically, there is some motivation to + automate the rollover process. Consider that: + + o ZSK rollovers are easy to automate as only the child zone is + involved. + o A KSK rollover needs interaction between parent and child. Data + exchange is needed to provide the new keys to the parent, + consequently, this data must be authenticated and integrity must + + + +Kolkman & Gieben Expires September 7, 2006 [Page 21] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + be guaranteed in order to avoid attacks on the rollover. + +4.3. Planning for Emergency Key Rollover + + This section deals with preparation for a possible key compromise. + Our advice is to have a documented procedure ready for when a key + compromise is suspected or confirmed. + + When the private material of one of your keys is compromised it can + be used for as long as a valid trust chain exists. A trust chain + remains intact for: + o as long as a signature over the compromised key in the trust chain + is valid, + o as long as a parental DS RR (and signature) points to the + compromised key, + o as long as the key is anchored in a resolver and is used as a + starting point for validation (this is generally the hardest to + update). + + While a trust chain to your compromised key exists, your name-space + is vulnerable to abuse by anyone who has obtained illegitimate + possession of the key. Zone operators have to make a 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 + trust 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. + +4.3.1. KSK Compromise + + A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable + as long as the compromised KSK is configured as trust anchor or a + parental DS points to it. + + A compromised KSK can be used to sign the key set of an attacker's + zone. That zone could be used to poison the DNS. + + Therefore when the KSK has been compromised, the trust anchor or the + parental DS, should be replaced as soon as possible. It is local + policy whether to break the trust chain during the emergency + rollover. The trust chain would be broken when the compromised KSK + is removed from the child's zone while the parent still has a DS + pointing to the compromised KSK (the assumption is that there is only + one DS at the parent. If there are multiple DSs this does not apply + -- however the chain of trust of this particular key is broken). + + Note that an attacker's zone still uses the compromised KSK and the + + + +Kolkman & Gieben Expires September 7, 2006 [Page 22] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + presence of a parental DS would cause the data in this zone to appear + as valid. Removing the compromised key would cause the attacker's + zone to appear as valid and the child's zone as Bogus. Therefore we + advise not to remove the KSK before the parent has a DS to a new KSK + in place. + +4.3.1.1. Keeping the Chain of Trust Intact + + If we follow this advice the timing of the replacement of the KSK is + somewhat critical. The goal is to remove the compromised KSK as soon + as the new DS RR is available at the parent. And also make sure that + the signature made with a new KSK over the key set with the + compromised KSK in it expires just after the new DS appears at the + parent. Thus removing the old cruft in one swoop. + + The procedure is as follows: + 1. Introduce a new KSK into the key set, keep the compromised KSK in + the key set. + 2. Sign the key set, with a short validity period. The validity + period should expire shortly after the DS is expected to appear + in the parent and the old DSs have expired from caches. + 3. Upload the DS for this new key to the parent. + 4. Follow the procedure of the regular KSK rollover: Wait for the DS + to appear in the authoritative servers and then wait as long as + the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet + and modify/extend the expiration time. + 5. Remove the compromised DNSKEY RR from the zone and re-sign the + key set using your "normal" validity interval. + + An additional danger of a key compromise is that the compromised key + could be used to facilitate a legitimate DNSKEY/DS rollover and/or + nameserver changes at the parent. When that happens the domain may + be in dispute. An authenticated out-of-band and secure notify + mechanism to contact a parent is needed in this case. + + Note that this is only a problem when the DNSKEY and or DS records + are used for authentication at the parent. + +4.3.1.2. Breaking the Chain of Trust + + There are two methods to break the chain of trust. The first method + causes the child zone to appear as 'Bogus' to validating resolvers. + The other causes the the child zone to appear as 'insecure'. These + are described below. + + In the method that causes the child zone to appear as 'Bogus' to + validating resolvers, the child zone replaces the current KSK with a + new one and resigns the key set. Next it sends the DS of the new key + + + +Kolkman & Gieben Expires September 7, 2006 [Page 23] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + to the parent. Only after the parent has placed the new DS in the + zone, the child's chain of trust is repaired. + + An alternative method of breaking the chain of trust is by removing + the DS RRs from the parent zone altogether. As a result the child + zone would become insecure. + +4.3.2. ZSK Compromise + + Primarily because there is no parental interaction required when a + ZSK is compromised, the situation is less severe than with a KSK + compromise. The zone must still be re-signed 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 of the old + compromised key may lead to verification problems. Also note that as + long as the RRSIG over the compromised ZSK is not expired the zone + may be still at risk. + +4.3.3. Compromises of Keys Anchored in Resolvers + + A key can also be pre-configured in resolvers. For instance, if + DNSSEC is successfully deployed the root key may be pre-configured in + most security aware resolvers. + + If trust-anchor keys are compromised, the resolvers using these keys + should be notified of this fact. Zone administrators may consider + setting up a mailing list to communicate the fact that a SEP key is + about to be rolled over. This communication will of course need to + be authenticated e.g. by using digital signatures. + + End-users faced with the task of updating an anchored key should + always validate the new key. New keys should be authenticated out- + of-band, for example, looking them up on an SSL secured announcement + website. + +4.4. Parental Policies + +4.4.1. Initial Key Exchanges and Parental Policies Considerations + + The initial key exchange is always subject to the policies set by the + parent. When designing a key exchange policy one should take into + account that the authentication and authorization mechanisms used + during a key exchange should be as strong as the authentication and + authorization mechanisms used for the exchange of delegation + information between parent and child. I.e. there is no implicit need + in DNSSEC to make the authentication process stronger than it was in + + + +Kolkman & Gieben Expires September 7, 2006 [Page 24] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + DNS. + + Using the DNS itself as the source for the actual DNSKEY material, + with an out-of-band check on the validity of the DNSKEY, has the + benefit that it reduces the chances of user error. A DNSKEY query + tool can make use of the SEP bit [3] to select the proper key from a + DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is + sent. It can validate the self-signature over a key; thereby + verifying the ownership of the private key material. Fetching the + DNSKEY from the DNS ensures that the chain of trust remains intact + once the parent publishes the DS RR indicating the child is secure. + + Note: the out-of-band verification is still needed when the key- + material is fetched via the DNS. The parent can never be sure + whether the DNSKEY RRs have been spoofed or not. + +4.4.2. Storing Keys or Hashes? + + When designing a registry system one should consider which of the + DNSKEYs and/or the corresponding DSs to store. Since a child zone + might wish to have a DS published using a message digest algorithm + not yet understood by the registry, the registry can't count on being + able to generate the DS record from a raw DNSKEY. Thus, we recommend + that registry systems at least support storing DS records. + + It may also be useful to store DNSKEYs, since having them may help + during troubleshooting and, as long as the child's chosen message + digest is supported, the overhead of generating DS records from them + is minimal. Having an out-of-band mechanism, such as a registry + directory (e.g. Whois), to find out which keys are used to generate + DS Resource Records for specific owners and/or zones may also help + with troubleshooting. + + The storage considerations also relate to the design of the customer + interface and the method by which data is transferred between + registrant and registry; Will the child zone administrator be able to + upload DS RRs with unknown hash algorithms or does the interface only + allow DNSKEYs? In the registry-registrar model one can use the + DNSSEC EPP protocol extension [16] which allows transfer of DS RRs + and optionally DNSKEY RRs. + +4.4.3. Security Lameness + + Security Lameness is defined as what happens when a parent has a DS + RR pointing to a non-existing DNSKEY RR. When this happens the + child's zone may be marked as "Bogus" by verifying DNS clients. + + As part of a comprehensive delegation check the parent could, at key + + + +Kolkman & Gieben Expires September 7, 2006 [Page 25] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + exchange time, verify that the child's key is actually configured in + the DNS. However if a parent does not understand the hashing + algorithm used by child the parental checks are limited to only + comparing the key id. + + Child zones should be very careful removing DNSKEY material, + specifically SEP keys, for which a DS RR exists. + + Once a zone is "security lame", a fix (e.g. removing a DS RR) will + take time to propagate through the DNS. + +4.4.4. DS Signature Validity Period + + Since the DS can be replayed as long as it has a valid signature, a + short signature validity period over the DS minimizes the time a + child is vulnerable in the case of a compromise of the child's + KSK(s). A signature validity period that is too short introduces the + possibility that a zone is marked Bogus in case of a configuration + error in the signer. There may not be enough time to fix the + problems before signatures expire. Something as mundane as operator + unavailability during weekends shows the need for DS signature + validity periods longer than 2 days. We recommend an absolute + minimum for a DS signature validity period of a few days. + + The maximum signature validity period of the DS record depends on how + long child zones are willing to be vulnerable after a key compromise. + On the other hand shortening the DS signature validity interval + increases the operational risk for the parent. Therefore the parent + may have policy to use a signature validity interval that is + considerably longer than the child would hope for. + + A compromise between the operational constraints of the parent and + minimizing damage for the child may result in a DS signature validity + period somewhere between the order of a week to order of months. + + In addition to the signature validity period, which sets a lower + bound on the number of times the zone owner will need to sign the + zone data and which sets an upper bound to the time a child is + vulnerable after key compromise, there is the TTL value on the DS + RRs. Shortening the TTL means that the authoritative servers will + see more queries. But on the other hand, a short TTL lowers the + persistence of DS RRSets in caches thereby increases the speed with + which updated DS RRSets propagate through the DNS. + + +5. IANA Considerations + + This overview document introduces no new IANA considerations. + + + +Kolkman & Gieben Expires September 7, 2006 [Page 26] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +6. Security Considerations + + DNSSEC adds data integrity to the DNS. This document tries to assess + the operational considerations to maintain a stable and secure DNSSEC + service. Not taking into account the 'data propagation' properties + in the DNS will cause validation failures and may make secured zones + unavailable to security aware resolvers. + + +7. Acknowledgments + + Most of the ideas in this draft were the result of collective efforts + during workshops, discussions and try outs. + + At the risk of forgetting individuals who were the original + contributors of the ideas we would like to acknowledge people who + were actively involved in the compilation of this document. In + random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael + Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette + Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger + Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch. + + Some material in this document has been copied from RFC 2541 [12]. + + Mike StJohns designed the key exchange between parent and child + mentioned in the last paragraph of Section 4.2.2 + + Section 4.2.4 was supplied by G. Guette and O. Courtay. + + Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of + the spelling and style issues. + + Kolkman and Gieben take the blame for introducing all miscakes(SIC). + + Kolkman was employed by the RIPE NCC while working on this document. + + +8. References + +8.1. 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] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY + + + +Kolkman & Gieben Expires September 7, 2006 [Page 27] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + +8.2. Informative References + + [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)", RFC 1996, August 1996. + + [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [10] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + [12] Eastlake, D., "DNS Security Operational Considerations", + RFC 2541, March 1999. + + [13] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [14] Orman, H. and P. Hoffman, "Determining Strengths For Public + Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, + April 2004. + + [15] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [16] Hollenbeck, S., "Domain Name System (DNS) Security Extensions + Mapping for the Extensible Provisioning Protocol (EPP)", + RFC 4310, December 2005. + + + +Kolkman & Gieben Expires September 7, 2006 [Page 28] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + [17] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key + Sizes", The Journal of Cryptology 14 (255-293), 2001. + + [18] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and + Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN + (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., + 1996. + + [19] Rose, S., "NIST DNSSEC workshop notes", June 2001. + + [20] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource + Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt + (work in progress), January 2006. + + [21] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) + Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt + (work in progress), January 2006. + + +Appendix A. Terminology + + In this document there is some jargon used that is defined in other + documents. In most cases we have not copied the text from the + documents defining the terms but given a more elaborate explanation + of the meaning. Note that these explanations should not be seen as + authoritative. + + Anchored Key: A DNSKEY configured in resolvers around the globe. + This key is hard to update, hence the term anchored. + Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked + "Bogus" when a signature of a RRSet does not validate against a + DNSKEY. + Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used + exclusively for signing the apex key set. The fact that a key is + a KSK is only relevant to the signing tool. + Key size: The term 'key size' can be substituted by 'modulus size' + throughout the document. It is mathematically more correct to use + modulus size, but as this is a document directed at operators we + feel more at ease with the term key size. + 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 (mathematically related) 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. + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 29] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + Key Rollover: A key rollover (also called key supercession in some + environments) is the act of replacing one key pair by another at + the end of a key effectivity period. + Secure Entry Point key or SEP Key: A KSK that has a parental DS + record pointing to it or is configured as a trust anchor. + Although not required by the protocol we recommend that the SEP + flag [3] is set on these keys. + Self-signature: This is only applies to signatures over DNSKEYs; a + signature made with DNSKEY x, over DNSKEY x is called a self- + signature. Note: without further information self-signatures + convey no trust, they are useful to check the authenticity of the + DNSKEY, i.e. they can be used as a hash. + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. + Signer: The system that has access to the private key material and + signs the Resource Record sets in a zone. A signer may be + configured to sign only parts of the zone e.g. only those RRSets + for which existing signatures are about to expire. + Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is + used for signing all data in a zone. The fact that a key is a ZSK + is only relevant to the signing tool. + Zone Administrator: The 'role' that is responsible for signing a zone + and publishing it on the primary authoritative server. + + +Appendix B. Zone Signing Key Rollover Howto + + Using the pre-published signature scheme and the most conservative + method to assure oneself that data does not live in caches, here + follows the "HOWTO". + Step 0: The preparation: Create two keys and publish both in your key + set. Mark one of the keys as "active" and the other as + "published". Use the "active" key for signing your zone data. + Store the private part of the "published" key, preferably off- + line. + The protocol does not provide for attributes to mark a key as + active or published. This is something you have to do on your + own, through the use of a notebook or key management tool. + Step 1: Determine expiration: At the beginning of the rollover make a + note of the highest expiration time of signatures in your zone + file created with the current key marked as "active". + Wait until the expiration time marked in Step 1 has passed + Step 2: Then start using the key that was marked as "published" to + sign your data i.e. mark it as "active". Stop using the key that + was marked as "active", mark it as "rolled". + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 30] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + 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 DNSKEYx, where x is a number or an + identifier, 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.0.2.1" is reduced to "A". RRSets are a + list of RRs. A example of this would be: "A1, A2", specifying the + RRSet containing two "A" records. This could again be abbreviated + to just "A". + Signature notation: Signatures are denoted as RRSIGx(RRSet), which + means that RRSet is signed with DNSKEYx. + Zone representation: Using the above notation we have simplified the + representation of a signed zone by leaving out all unnecessary + details such as the names and by representing all data by "SOAx" + SOA representation: SOAs are represented as SOAx, where x is the + serial number. + Using this notation the following signed zone: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 31] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + example.net. 86400 IN SOA ns.example.net. bert.example.net. ( + 2006022100 ; serial + 86400 ; refresh ( 24 hours) + 7200 ; retry ( 2 hours) + 3600000 ; expire (1000 hours) + 28800 ) ; minimum ( 8 hours) + 86400 RRSIG SOA 5 2 86400 20130522213204 ( + 20130422213204 14 example.net. + cmL62SI6iAX46xGNQAdQ... ) + 86400 NS a.iana-servers.net. + 86400 NS b.iana-servers.net. + 86400 RRSIG NS 5 2 86400 20130507213204 ( + 20130407213204 14 example.net. + SO5epiJei19AjXoUpFnQ ... ) + 86400 DNSKEY 256 3 5 ( + EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 + 86400 DNSKEY 257 3 5 ( + gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 + 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( + 20130422213204 14 example.net. + J4zCe8QX4tXVGjV4e1r9... ) + 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( + 20130422213204 15 example.net. + keVDCOpsSeDReyV6O... ) + 86400 RRSIG NSEC 5 2 86400 20130507213204 ( + 20130407213204 14 example.net. + obj3HEp1GjnmhRjX... ) + a.example.net. 86400 IN TXT "A label" + 86400 RRSIG TXT 5 3 86400 20130507213204 ( + 20130407213204 14 example.net. + IkDMlRdYLmXH7QJnuF3v... ) + 86400 NSEC b.example.com. TXT RRSIG NSEC + 86400 RRSIG NSEC 5 3 86400 20130507213204 ( + 20130407213204 14 example.net. + bZMjoZ3bHjnEz0nIsPMM... ) + ... + + is reduced to the following representation: + + SOA2006022100 + RRSIG14(SOA2006022100) + DNSKEY14 + DNSKEY15 + + RRSIG14(KEY) + RRSIG15(KEY) + + The rest of the zone data has the same signature as the SOA record, + + + +Kolkman & Gieben Expires September 7, 2006 [Page 32] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + i.e a RRSIG created with DNSKEY 14. + + +Appendix D. Document Details and Changes + + This section is to be removed by the RFC editor if and when the + document is published. + + $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14 + 2005/03/21 15:51:41 dnssec Exp $ + +D.1. draft-ietf-dnsop-dnssec-operational-practices-00 + + Submission as working group document. This document is a modified + and updated version of draft-kolkman-dnssec-operational-practices-00. + +D.2. draft-ietf-dnsop-dnssec-operational-practices-01 + + changed the definition of "Bogus" to reflect the one in the protocol + draft. + + Bad to Bogus + + Style and spelling corrections + + KSK - SEP mapping made explicit. + + Updates from Sam Weiler added + +D.3. draft-ietf-dnsop-dnssec-operational-practices-02 + + Style and errors corrected. + + Added Automatic rollover requirements from I-D.ietf-dnsop-key- + rollover-requirements. + +D.4. draft-ietf-dnsop-dnssec-operational-practices-03 + + Added the definition of Key effectivity period and used that term + instead of Key validity period. + + Modified the order of the sections, based on a suggestion by Rip + Loomis. + + Included parts from RFC 2541 [12]. Most of its ground was already + covered. This document obsoletes RFC 2541 [12]. Section 3.1.2 + deserves some review as it in contrast to RFC 2541 does _not_ give + recomendations about root-zone keys. + + + +Kolkman & Gieben Expires September 7, 2006 [Page 33] + +Internet-Draft DNSSEC Operational Practices March 2006 + + + added a paragraph to Section 4.4.4 + +D.5. draft-ietf-dnsop-dnssec-operational-practices-04 + + Somewhat more details added about the pre-publish KSK rollover. Also + moved that subsection down a bit. + + Editorial and content nits that came in during wg last call were + fixed. + +D.6. draft-ietf-dnsop-dnssec-operational-practices-05 + + Applied some another set of comments that came in _after_ the the + WGLC. + + Applied comments from Hilarie Orman and made a referece to RFC 3766. + Deleted of a lot of key length discussion and took over the + recommendations from RFC 3766. + + Reworked all the heading of the rollover figures + +D.7. draft-ietf-dnsop-dnssec-operational-practices-06 + + One comment from Scott Rose applied. + + Marcos Sanz gave a lots of editorial nits. Almost all are + incorporated. + +D.8. draft-ietf-dnsop-dnssec-operational-practices-07 + + Peter Koch's comments applied. + + SHA-1/SHA-256 remarks added + +D.9. draft-ietf-dnsop-dnssec-operational-practices-08 + + IESG comments applied. Added headers and some captions to the tables + and applied all the nits. + + IESG DISCUSS comments applied + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 34] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +Authors' Addresses + + Olaf M. Kolkman + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + Email: olaf@nlnetlabs.nl + URI: http://www.nlnetlabs.nl + + + Miek Gieben + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + Email: miek@nlnetlabs.nl + URI: http://www.nlnetlabs.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 35] + +Internet-Draft DNSSEC Operational Practices March 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Kolkman & Gieben Expires September 7, 2006 [Page 36] + diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt new file mode 100644 index 0000000..c6ec7e4 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt @@ -0,0 +1,618 @@ + + + + +Network Working Group S. Woolf +Internet-Draft Internet Systems Consortium, Inc. +Expires: September 6, 2006 D. Conrad + Nominum, Inc. + March 5, 2006 + + + Requirements for a Mechanism Identifying a Name Server Instance + draft-ietf-dnsop-serverid-06 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on September 6, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid for + administrators. Existing ad hoc mechanisms for addressing this need + + + +Woolf & Conrad Expires September 6, 2006 [Page 1] + +Internet-Draft Serverid March 2006 + + + have some shortcomings, not the least of which is the lack of prior + analysis of exactly how such a mechanism should be designed and + deployed. This document describes the existing convention used in + some widely deployed implementations of the DNS protocol, including + advantages and disadvantages, and discusses some attributes of an + improved mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 2] + +Internet-Draft Serverid March 2006 + + +1. Introduction and Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. This is most obviously useful for authoritative + nameservers in the attempt to diagnose the source or prevalence of + inaccurate data, but can also conceivably be useful for caching + resolvers in similar and other situations. Furthermore, the ability + to identify which server is responding to a query has become more + useful as DNS has become more critical to more Internet users, and as + network and server deployment topologies have become more complex. + + The traditional means for determining which of several possible + servers is answering a query has traditionally been based on the use + of the server's IP address as a unique identifier. However, the + modern Internet has seen the deployment of various load balancing, + fault-tolerance, or attack-resistance schemes such as shared use of + unicast IP addresses as documented in [RFC3258]. An unfortunate side + effect of these schemes has been to make the use of IP addresses as + identifiers somewhat problematic. Specifically, a dedicated DNS + query may not go to the same server as answered a previous query, + even though sent to the same IP address. Non-DNS methods such as + ICMP ping, TCP connections, or non-DNS UDP packets (such as those + generated by tools like "traceroute"), etc., may well be even less + certain to reach the same server as the one which receives the DNS + queries. + + There is a well-known and frequently-used technique for determining + an identity for a nameserver more specific than the possibly-non- + unique "server that answered the query I sent to IP address XXX". + The widespread use of the existing convention suggests a need for a + documented, interoperable means of querying the identity of a + nameserver that may be part of an anycast or load-balancing cluster. + At the same time, however, it also has some drawbacks that argue + against standardizing it as it's been practiced so far. + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 3] + +Internet-Draft Serverid March 2006 + + +2. Existing Conventions + + For some time, the commonly deployed Berkeley Internet Name Domain + implementation of the DNS protocol suite from the Internet Systems + Consortium [BIND] has supported a way of identifying a particular + server via the use of a standards-compliant, if somewhat unusual, DNS + query. Specifically, a query to a recent BIND server for a TXT + resource record in class 3 (CHAOS) for the domain name + "HOSTNAME.BIND." will return a string that can be configured by the + name server administrator to provide a unique identifier for the + responding server. (The value defaults to the result of a + gethostname() call). This mechanism, which is an extension of the + BIND convention of using CHAOS class TXT RR queries to sub-domains of + the "BIND." domain for version information, has been copied by + several name server vendors. + + A refinement to the BIND-based mechanism, which dropped the + implementation-specific string, replaces ".BIND" with ".SERVER". + Thus the query string to learn the unique name of a server may be + queried as "ID.SERVER". + + (For reference, the other well-known name used by recent versions of + BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A + query for a CHAOS TXT RR for this name will return an + administratively defined string which defaults to the version of the + server responding. This is, however, not generally implemented by + other vendors.) + +2.1. Advantages + + There are several valuable attributes to this mechanism, which + account for its usefulness. + + 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is + within the DNS protocol itself. An identification mechanism that + relies on the DNS protocol is more likely to be successful + (although not guaranteed) in going to the same system as a + "normal" DNS query. + + 2. Since the identity information is requested and returned within + the DNS protocol, it doesn't require allowing any other query + mechanism to the server, such as holes in firewalls for + otherwise-unallowed ICMP Echo requests. Thus it is likely to + reach the same server over a path subject to the same routing, + resource, and security policy as the query, without any special + exceptions to site security policy. + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 4] + +Internet-Draft Serverid March 2006 + + + 3. It is simple to configure. An administrator can easily turn on + this feature and control the results of the relevant query. + + 4. It allows the administrator complete control of what information + is given out in the response, minimizing passive leakage of + implementation or configuration details. Such details are often + considered sensitive by infrastructure operators. + + 5. Hypothetically, since it's an ordinary DNS record and the + relevant DNSSEC RRs are class independent, the id.server response + RR could be signed, which has the advantages described in + [RFC4033]. + +2.2. Disadvantages + + At the same time, there are some serious drawbacks to the CHAOS/TXT + query mechanism that argue against standardizing it as it currently + operates. + + 1. It requires an additional query to correlate between the answer + to a DNS query under normal conditions and the supposed identity + of the server receiving the query. There are a number of + situations in which this simply isn't reliable. + + 2. It reserves an entire class in the DNS (CHAOS) for what amounts + to one zone. While CHAOS class is defined in [RFC1034] and + [RFC1035], it's not clear that supporting it solely for this + purpose is a good use of the namespace or of implementation + effort. + + 3. The initial and still common form, using .BIND, is implementation + specific. BIND is one DNS implementation. At the time of this + writing, it is probably the most prevalent for authoritative + servers. This does not justify standardizing on its ad hoc + solution to a problem shared across many operators and + implementors. Meanwhile, the proposed refinement changes the + string but preserves the ad hoc CHAOS/TXT mechanism. + + 4. There is no convention or shared understanding of what + information an answer to such a query for a server identity could + or should include, including a possible encoding or + authentication mechanism. + + The first of the listed disadvantages may be technically the most + serious. It argues for an attempt to design a good answer to the + problem that "I need to know what nameserver is answering my + queries", not simply a convenient one. + + + + +Woolf & Conrad Expires September 6, 2006 [Page 5] + +Internet-Draft Serverid March 2006 + + +2.3. Characteristics of an Implementation Neutral Convention + + The discussion above of advantages and disadvantages to the + HOSTNAME.BIND mechanism suggest some requirements for a better + solution to the server identification problem. These are summarized + here as guidelines for any effort to provide appropriate protocol + extensions: + + 1. The mechanism adopted must be in-band for the DNS protocol. That + is, it needs to allow the query for the server's identifying + information to be part of a normal, operational query. It should + also permit a separate, dedicated query for the server's + identifying information. But it should preserve the ability of + the CHAOS/TXT query-based mechanism to work through firewalls and + in other situations where only DNS can be relied upon to reach + the server of interest. + + 2. The new mechanism should not require dedicated namespaces or + other reserved values outside of the existing protocol mechanisms + for these, i.e. the OPT pseudo-RR. In particular, it should not + propagate the existing drawback of requiring support for a CLASS + and top level domain in the authoritative server (or the querying + tool) to be useful. + + 3. Support for the identification functionality should be easy to + implement and easy to enable. It must be easy to disable and + should lend itself to access controls on who can query for it. + + 4. It should be possible to return a unique identifier for a server + without requiring the exposure of information that may be non- + public and considered sensitive by the operator, such as a + hostname or unicast IP address maintained for administrative + purposes. + + 5. It should be possible to authenticate the received data by some + mechanism analogous to those provided by DNSSEC. In this + context, the need could be met by including encryption options in + the specification of a new mechanism. + + 6. The identification mechanism should not be implementation- + specific. + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 6] + +Internet-Draft Serverid March 2006 + + +3. IANA Considerations + + This document proposes no specific IANA action. Protocol extensions, + if any, to meet the requirements described are out of scope for this + document. A proposed extension, specified and adopted by normal IETF + process, is described in [NSID], including relevant IANA action. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 7] + +Internet-Draft Serverid March 2006 + + +4. Security Considerations + + Providing identifying information as to which server is responding to + a particular query from a particular location in the Internet can be + seen as information leakage and thus a security risk. This motivates + the suggestion above that a new mechanism for server identification + allow the administrator to disable the functionality altogether or + partially restrict availability of the data. It also suggests that + the serverid data should not be readily correlated with a hostname or + unicast IP address that may be considered private to the nameserver + operator's management infrastructure. + + Propagation of protocol or service meta-data can sometimes expose the + application to denial of service or other attack. As DNS is a + critically important infrastructure service for the production + Internet, extra care needs to be taken against this risk for + designers, implementors, and operators of a new mechanism for server + identification. + + Both authentication and confidentiality of serverid data are + potentially of interest to administrators-- that is, operators may + wish to make serverid data available and reliable to themselves and + their chosen associates only. This would imply both an ability to + authenticate it to themselves and keep it private from arbitrary + other parties. This led to Characteristics 4 and 5 of an improved + solution. + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 8] + +Internet-Draft Serverid March 2006 + + +5. Acknowledgements + + The technique for host identification documented here was initially + implemented by Paul Vixie of the Internet Software Consortium in the + Berkeley Internet Name Daemon package. Comments and questions on + earlier drafts were provided by Bob Halley, Brian Wellington, Andreas + Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the + ICANN Root Server System Advisory Committee. The newest version + takes a significantly different direction from previous versions, + owing to discussion among contributors to the DNSOP working group and + others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam + Weiler, and Rob Austein. + +6. References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", + RFC 1034, STD 0013, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, STD 0013, November 1987. + + [3] Hardie, T., "Distributing Authoritative Name Servers via Shared + Unicast Addresses", RFC 3258, April 2002. + + [4] ISC, "BIND 9 Configuration Reference". + + [5] Austein, S., "DNS Name Server Identifier Option (NSID)", + Internet Drafts http://www.ietf.org/internet-drafts/ + draft-ietf-dnsext-nsid-01.txt, January 2006. + + [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 9] + +Internet-Draft Serverid March 2006 + + +Authors' Addresses + + Suzanne Woolf + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + US + + Phone: +1 650 423-1333 + Email: woolf@isc.org + URI: http://www.isc.org/ + + + David Conrad + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + US + + Phone: +1 1 650 381 6003 + Email: david.conrad@nominum.com + URI: http://www.nominum.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Expires September 6, 2006 [Page 10] + +Internet-Draft Serverid March 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Woolf & Conrad Expires September 6, 2006 [Page 11] + + diff --git a/contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt b/contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt new file mode 100644 index 0000000..3bd9594 --- /dev/null +++ b/contrib/bind9/doc/draft/draft-schlitt-spf-classic-02.txt @@ -0,0 +1,3136 @@ + + + +Network Working Group M. Wong +Internet-Draft W. Schlitt +Expires: December 8, 2005 June 6, 2005 + + +Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, + version 1 + draft-schlitt-spf-classic-02 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on December 8, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + E-mail on the Internet can be forged in a number of ways. In + particular, existing protocols place no restriction on what a sending + host can use as the reverse-path of a message or the domain given on + the SMTP HELO/EHLO commands. This document describes version 1 of + the SPF protocol, whereby a domain may explicitly authorize the hosts + that are allowed to use its domain name, and a receiving host may + check such authorization. + + + + +Wong & Schlitt Expires December 8, 2005 [Page 1] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. State of this draft . . . . . . . . . . . . . . . . . . . 4 + 1.2. Protocol Status . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. The HELO Identity . . . . . . . . . . . . . . . . . . . . 6 + 2.2. The MAIL FROM Identity . . . . . . . . . . . . . . . . . . 6 + 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 6 + 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 7 + 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 8 + 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.5.5. SoftFail . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 10 + 2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 10 + 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 11 + 3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 12 + 3.1.3. Multiple Strings in a Single DNS record . . . . . . . 12 + 3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 12 + 3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 13 + 4. The check_host() Function . . . . . . . . . . . . . . . . . . 14 + 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 14 + 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 15 + 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 15 + 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 15 + 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 16 + 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 16 + 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 17 + 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 17 + 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 17 + 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 19 + 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 20 + 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.5. "ptr" . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 23 + 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 25 + 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 25 + + + +Wong & Schlitt Expires December 8, 2005 [Page 2] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 26 + 7. The Received-SPF header field . . . . . . . . . . . . . . . . 28 + 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 8.1. Macro definitions . . . . . . . . . . . . . . . . . . . . 30 + 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 33 + 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 34 + 9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 34 + 9.3. Forwarding Services and Aliases . . . . . . . . . . . . . 34 + 9.4. Mail Services . . . . . . . . . . . . . . . . . . . . . . 36 + 9.5. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 37 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 38 + 10.2. SPF-Authorized E-Mail May Be UBE . . . . . . . . . . . . . 39 + 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 40 + 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 40 + 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 40 + 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 41 + 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 42 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 43 + 12.2. The Received-SPF mail header . . . . . . . . . . . . . . . 43 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 + Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46 + Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 48 + B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 48 + B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 49 + B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 50 + B.4. Multiple Requirements Example . . . . . . . . . . . . . . 50 + Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 51 + C.1. Changes in Version -02 . . . . . . . . . . . . . . . . . . 51 + C.2. Changes in Version -01 . . . . . . . . . . . . . . . . . . 52 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 55 + Intellectual Property and Copyright Statements . . . . . . . . . . 56 + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 3] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +1. Introduction + + The current e-mail infrastructure has the property that any host + injecting mail into the mail system can identify itself as any domain + name it wants. Hosts can do this at a variety of levels: in + particular, the session, the envelope, and the mail headers. While + this feature is desirable in some circumstances, it is a major + obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam"). + Furthermore, many domain name holders are understandably concerned + about the ease with which other entities may make use of their domain + names, often with malicious intent. + + This document defines a protocol by which domain owners may authorize + hosts to use their domain name in the "MAIL FROM" or "HELO" identity. + Compliant domain holders publish SPF records specifying which hosts + are permitted to use their names, and compliant mail receivers use + the published SPF records to test the authorization of sending MTAs + using a given "HELO" or "MAIL FROM" identity during a mail + transaction. + + An additional benefit to mail receivers is that after the use of an + identity is verified, local policy decisions about the mail can be + made based on the sender's domain, rather than the host's IP address. + This is advantageous because reputation of domain names is likely to + be more accurate than reputation of host IP addresses. Furthermore, + if a claimed identity fails verification, local policy can take + stronger action against such e-mail, such as rejecting it. + +1.1. State of this draft + + This draft version attempts to resolve all known issues and address + all comments received from the IESG review of 2005/02/17, as well + reviews from the namedroppers, ietf-smtp, ietf-822 and spf-discuss + mailing lists both in January and in May. + + Please check the Change log in Appendix C before proposing changes, + as it is possible that your idea has already been discussed. Please + post comments on the spf-discuss@v2.listbox.com mailing list or + e-mail them directly to the author. + + I am sorry for the length of this I-D; I have not had time to make it + shorter. + + RFC Editor Note: Please remove this section for the final publication + of the document. It has been inspired by + draft-ietf-tools-draft-submission-09.txt. + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 4] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +1.2. Protocol Status + + SPF has been in development since the Summer of 2003, and has seen + deployment beyond the developers beginning in December, 2003. The + design of SPF slowly evolved until the spring of 2004 and has since + stabilized. There have been quite a number of forms of SPF, some + written up as documents, some submitted as Internet Drafts, and many + discussed and debated in development forums. + + The goal of this document is to clearly document the protocol defined + by earlier draft specifications of SPF as used in existing + implementations. This conception of SPF is sometimes called "SPF + Classic". It is understood that particular implementations and + deployments may differ from, and build upon, this work. It is hoped + that we have nonetheless captured the common understanding of SPF + version 1. + +1.3. 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 [RFC2119]. + + This document is concerned with the portion of a mail message + commonly called "envelope sender", "return path", "reverse path", + "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are + either not well defined, or often used casually, this document + defines the "MAIL FROM" identity in Section 2.2. Note that other + terms that may superficially look like the common terms, such as + "reverse-path", are used only with the defined meanings from + normative documents. + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 5] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +2. Operation + +2.1. The HELO Identity + + The "HELO" identity derives from either the SMTP HELO or EHLO command + (see [RFC2821]). These commands supply the SMTP client (sending + host) for the SMTP session. Note that requirements for the domain + presented in the EHLO or HELO command are not always clear to the + sending party, and SPF clients must be prepared for the "HELO" + identity to be malformed or an IP address literal. At the time of + this writing, many legitimate e-mails are delivered with invalid HELO + domains. + + It is RECOMMENDED that SPF clients check not only the "MAIL FROM" + identity, but also separately check the "HELO" identity by applying + the check_host() function (Section 4) to the "HELO" identity as the + <sender>. + +2.2. The MAIL FROM Identity + + The "MAIL FROM" identity derives from the SMTP MAIL command (see + [RFC2821]). This command supplies the "reverse-path" for a message, + which generally consists of the sender mailbox, and is the mailbox to + which notification messages are to be sent if there are problems + delivering the message. + + [RFC2821] allows the reverse-path to be null (see Section 4.5.5). In + this case, there is no explicit sender mailbox, and such a message + can be assumed to be a notification message from the mail system + itself. When the reverse-path is null, this document defines the + "MAIL FROM" identity to be the mailbox composed of the localpart + "postmaster" and the "HELO" identity (which may or may not have been + checked separately before). + + SPF clients MUST check the "MAIL FROM" identity. SPF clients check + the "MAIL FROM" identity by applying the check_host() function to the + "MAIL FROM" identity as the <sender>. + +2.3. Publishing Authorization + + An SPF-compliant domain MUST publish a valid SPF record as described + in Section 3. This record authorizes the use of the domain name in + the "HELO" and "MAIL FROM" identities by the MTAs it specifies. + + If domain owners choose to publish SPF records, it is RECOMMENDED + that they end in "-all", or redirect to other records that do, so + that a definitive determination of authorization can be made. + + + + +Wong & Schlitt Expires December 8, 2005 [Page 6] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + Domain holders may publish SPF records that explicitly authorize no + hosts if mail should never originate using that domain. + + When changing SPF records, care must be taken to ensure that there is + a transition period so that the old policy remains valid until all + legitimate e-mail has been checked. + +2.4. Checking Authorization + + A mail receiver can perform a set of SPF checks for each mail message + it receives. An SPF check tests the authorization of a client host + to emit mail with a given identity. Typically, such checks are done + by a receiving MTA, but can be performed elsewhere in the mail + processing chain so long as the required information is available and + reliable. At least the "MAIL FROM" identity MUST be checked, but it + is RECOMMENDED that the "HELO" identity also be checked beforehand. + + Without explicit approval of the domain owner, checking other + identities against SPF version 1 records is NOT RECOMMENDED because + there are cases that are known to give incorrect results. For + example, almost all mailing lists rewrite the "MAIL FROM" identity + (see Section 9.2), but some do not change any other identities in the + message. The scenario described in Section 9.3.1.2 is another + example. Documents that define other identities should define the + method for explicit approval. + + It is possible that mail receivers will use the SPF check as part of + a larger set of tests on incoming mail. The results of other tests + may influence whether or not a particular SPF check is performed. + For example, finding the sending host's IP address on a local white + list may cause all other tests to be skipped and all mail from that + host to be accepted. + + When a mail receiver decides to perform an SPF check, it MUST use a + correctly-implemented check_host() function (Section 4) evaluated + with the correct parameters. While the test as a whole is optional, + once it has been decided to perform a test it must be performed as + specified so that the correct semantics are preserved between + publisher and receiver. + + To make the test, the mail receiver MUST evaluate the check_host() + function with the arguments set as follows: + + <ip> - the IP address of the SMTP client that is emitting the + mail, either IPv4 or IPv6. + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 7] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + <domain> - the domain portion of the "MAIL FROM" or "HELO" identity. + + <sender> - the "MAIL FROM" or "HELO" identity. + + Note that the <domain> argument may not be a well-formed domain name. + For example, if the reverse-path was null, then the EHLO/HELO domain + is used, with its associated problems (see Section 2.1). In these + cases, check_host() is defined in Section 4.3 to return a "None" + result. + + While invalid, malformed, or non-existent domains cause SPF checks to + return "None" because no SPF record can be found, it has long been + the policy of many MTAs to reject e-mail from such domains, + especially in the case of invalid "MAIL FROM". In order to prevent + the circumvention of SPF records, rejecting e-mail from invalid + domains should be considered. + + Implementations must take care to correctly extract the <domain> from + the data given with the SMTP MAIL FROM command as many MTAs will + still accept such things as source routes (see [RFC2821] appendix C), + the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These + archaic features have been maliciously used to bypass security + systems. + +2.5. Interpreting the Result + + This section describes how software that performs the authorization + should interpret the results of the check_host() function. The + authorization check SHOULD be performed during the processing of the + SMTP transaction that sends the mail. This allows errors to be + returned directly to the sending server by way of SMTP replies. + + Performing the authorization after the SMTP transaction has finished + may cause problems, such as: 1) It may be difficult to accurately + extract the required information from potentially deceptive headers. + 2) Legitimate e-mail may fail because the sender's policy may have + since changed. + + Generating non-delivery notifications to forged identities that have + failed the authorization check is generally abusive and against the + explicit wishes of the identity owner. + +2.5.1. None + + A result of "None" means that no records were published by the + domain, or that no checkable sender domain could be determined from + the given identity. The checking software cannot ascertain whether + the client host is authorized or not. + + + +Wong & Schlitt Expires December 8, 2005 [Page 8] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +2.5.2. Neutral + + The domain owner has explicitly stated that they cannot or do not + want to assert whether the IP address is authorized or not. A + "Neutral" result MUST be treated exactly like the "None" result; the + distinction exists only for informational purposes. Treating + "Neutral" more harshly than "None" will discourage domain owners from + testing the use of SPF records (see Section 9.1). + +2.5.3. Pass + + A "Pass" result means that the client is authorized to inject mail + with the given identity. The domain can now, in the sense of + reputation, be considered responsible for sending the message. + Further policy checks can now proceed with confidence in the + legitimate use of the identity. + +2.5.4. Fail + + A "Fail" result is an explicit statement that the client is not + authorized to use the domain in the given identity. The checking + software can choose to mark the mail based on this, or to reject the + mail outright. + + If the checking software chooses to reject the mail during the SMTP + transaction, then it SHOULD use an SMTP reply code of 550 (see + [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification + (DSN) code (see [RFC3464]), in addition to an appropriate reply text. + The check_host() function may return either a default explanation + string, or one from the domain that published the SPF records (see + Section 6.2). If the information doesn't originate with the checking + software, it should be made clear that the text is provided by the + sender's domain. For example: + + 550-5.7.1 SPF MAIL FROM check failed: + 550-5.7.1 The domain example.com explains: + 550 5.7.1 Please see http://www.example.com/mailpolicy.html + +2.5.5. SoftFail + + A "SoftFail" result should be treated as somewhere between a "Fail" + and a "Neutral". The domain believes the host isn't authorized but + isn't willing to make that strong of a statement. Receiving software + SHOULD NOT reject the message based solely on this result, but MAY + subject the message to closer scrutiny than normal. + + The domain owner wants to discourage the use of this host and so they + desire limited feedback when a "SoftFail" result occurs. For + + + +Wong & Schlitt Expires December 8, 2005 [Page 9] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + example, the recipient's MUA could highlight the "SoftFail" status, + or the receiving MTA could give the sender a message using a + technique called "greylisting" whereby the MTA can issue an SMTP + reply code of 451 (4.3.0 DSN code) with a note the first time the + message is received, but accept it the second time. + +2.5.6. TempError + + A "TempError" result means that the SPF client encountered a + transient error while performing the check. Checking software can + choose to accept or temporarily reject the message. If the message + is rejected during the SMTP transaction for this reason, the software + SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN + code. + +2.5.7. PermError + + A "PermError" result means that the domain's published records + couldn't be correctly interpreted. This signals an error condition + that requires manual intervention to be resolved, as opposed to the + TempError result. Be aware that if the domain owner uses macros + (Section 8), it is possible that this result is due to the checked + identities having an unexpected format. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 10] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +3. SPF Records + + An SPF record is a DNS Resource Record (RR) that declares which hosts + are, and are not, authorized to use a domain name for the "HELO" and + "MAIL FROM" identities. Loosely, the record partitions all hosts + into permitted and not-permitted sets. (Though some hosts might fall + into neither category.) + + The SPF record is a single string of text. An example record is: + + v=spf1 +mx a:colo.example.com/28 -all + + This record has a version of "spf1" and three directives: "+mx", + "a:colo.example.com/28" (the + is implied), and "-all". + +3.1. Publishing + + Domain owners wishing to be SPF compliant must publish SPF records + for the hosts that are used in the "MAIL FROM" and "HELO" identities. + The SPF records are placed in the DNS tree at the host name it + pertains to, not a subdomain under it, such as is done with SRV + records. This is the same whether the TXT or SPF RR type is used. + + The example above in Section 3 might be published via this lines in a + domain zone file: + + example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" + smtp-out.example.com. TXT "v=spf1 a -all" + + When publishing via TXT records, beware of other TXT records + published there for other purposes. They may cause problems with + size limits (see Section 3.1.4). + +3.1.1. DNS Resource Record Types + + This document defines a new DNS RR of type SPF, type code to be + determined. The format of this type is identical to the TXT RR + [RFC1035]. For either type, the character content of the record is + encoded as [US-ASCII]. + + RFC Editor Note: Please add the DNS RR type code once it has been + allocated by the IANA. + + It is recognized that the current practice (using a TXT record) is + not optimal, but it is necessary because there are a number of DNS + server and resolver implementations in common use that cannot handle + the new RR type. The two-record-type scheme provides a forward path + to the better solution of using an RR type reserved for this purpose. + + + +Wong & Schlitt Expires December 8, 2005 [Page 11] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + An SPF-compliant domain name SHOULD have SPF records of both RR + types. A compliant domain name MUST have a record of at least one + type. If a domain has records of both types, they MUST have + identical content. For example, instead of just publishing one + record as in Section 3.1 above, it is better to publish: + + example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" + example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" + + Example RRs in this document are shown with the TXT record type, + however they could be published with the SPF type or with both types. + +3.1.2. Multiple DNS Records + + A domain name MUST NOT have multiple records that would cause an + authorization check to select more than one record. See Section 4.5 + for the selection rules. + +3.1.3. Multiple Strings in a Single DNS record + + As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS + record (either TXT and SPF RR types) can be composed of more than one + string. If a published record contains multiple strings, then the + record MUST be treated as if those strings are concatenated together + without adding spaces. For example: + + IN TXT "v=spf1 .... first" "second string..." + + MUST be treated as equivalent to + + IN TXT "v=spf1 .... firstsecond string..." + + SPF or TXT records containing multiple strings are useful in order to + construct records which would exceed the 255 byte maximum length of a + string within a single TXT or SPF RR record. + +3.1.4. Record Size + + The published SPF record for a given domain name SHOULD remain small + enough that the results of a query for it will fit within 512 octets. + This will keep even older DNS implementations from falling over to + TCP. Since the answer size is dependent on many things outside the + scope of this document, it is only possible to give this guideline: + If the combined length of the DNS name and the text of all the + records of a given type (TXT or SPF) is under 450 characters, then + DNS answers should fit in UDP packets. Note that when computing the + sizes for queries of the TXT format, one must take into account any + other TXT records published at the domain name. Records that are too + + + +Wong & Schlitt Expires December 8, 2005 [Page 12] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + long to fit in a single UDP packet MAY be silently ignored by SPF + clients. + +3.1.5. Wildcard Records + + Use of wildcard records for publishing is not recommended. Care must + be taken if wildcard records are used. If a domain publishes + wildcard MX records, it may want to publish wildcard declarations, + subject to the same requirements and problems. In particular, the + declaration must be repeated for any host that has any RR records at + all, and for subdomains thereof. For example, the example given in + [RFC1034], Section 4.3.3, could be extended with: + + X.COM. MX 10 A.X.COM + X.COM. TXT "v=spf1 a:A.X.COM -all" + + *.X.COM. MX 10 A.X.COM + *.X.COM. TXT "v=spf1 a:A.X.COM -all" + + A.X.COM. A 1.2.3.4 + A.X.COM. MX 10 A.X.COM + A.X.COM. TXT "v=spf1 a:A.X.COM -all" + + *.A.X.COM. MX 10 A.X.COM + *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" + + Notice that SPF records must be repeated twice for every name within + the domain: once for the name, and once with a wildcard to cover the + tree under the name. + + Use of wildcards is discouraged in general as they cause every name + under the domain to exist and queries against arbitrary names will + never return RCODE 3 (Name Error). + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 13] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +4. The check_host() Function + + The check_host() function fetches SPF records, parses them, and + interprets them to determine whether a particular host is or is not + permitted to send mail with a given identity. Mail receivers that + perform this check MUST correctly evaluate the check_host() function + as described here. + + Implementations MAY use a different algorithm than the canonical + algorithm defined here, so long as the results are the same in all + cases. + +4.1. Arguments + + The function check_host() takes these arguments: + + <ip> - the IP address of the SMTP client that is emitting the + mail, either IPv4 or IPv6. + + <domain> - the domain that provides the sought-after authorization + information; initially the domain portion of the "MAIL FROM" + or "HELO" identity. + + <sender> - the "MAIL FROM" or "HELO" identity. + + The domain portion of <sender> will usually be the same as the + <domain> argument when check_host() is initially evaluated. However, + this will generally not be true for recursive evaluations (see + Section 5.2 below). + + Actual implementations of the check_host() function may need + additional arguments. + +4.2. Results + + The function check_host() can return one of several results described + in Section 2.5. Based on the result, the action to be taken is + determined by the local policies of the receiver. + +4.3. Initial Processing + + If the <domain> is malformed (label longer than 63 characters, zero + length label not at the end, etc.), is not a fully qualified domain + name, or if the DNS lookup returns "domain does not exist" (RCODE 3), + check_host() immediately returns the result "None". + + If the <sender> has no localpart, substitute the string "postmaster" + for the localpart. + + + +Wong & Schlitt Expires December 8, 2005 [Page 14] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +4.4. Record Lookup + + In accordance with how the records are published, see Section 3.1 + above, a DNS query needs to be made for the <domain> name, querying + for either RR type TXT, SPF, or both. If both SPF and TXT RRs are + looked up, the queries MAY be done in parallel. + + If the DNS lookup returns a server failure (RCODE 2), or other error + (RCODE other than 0 or 3), or the query times out, check_host() exits + immediately with the result "TempError". + +4.5. Selecting Records + + Records begin with a version section: + + record = version terms *SP + version = "v=spf1" + + Starting with the set of records that were returned by the lookup, + record selection proceeds in three steps: + + 1. Records that do not begin with a version section of exactly + "v=spf1" are discarded. Note that the version section is + terminated either by a SP character or the end of the record. A + record with a version section of "v=spf10" does not match and + must be discarded. + + 2. If there are both SPF and TXT records in the set and if they are + not all identical, return a "PermError". + + 3. If any records of type SPF are in the set, then all records of + type TXT are discarded. + + After the above steps, there should be exactly one record remaining + and evaluation can proceed. If there are two or more records + remaining, then check_host() exits immediately with the result of + "PermError". + + If no matching records are returned, an SPF client MUST assume that + the domain makes no SPF declarations. SPF processing MUST stop and + return "None". + +4.6. Record Evaluation + + After one SPF record has been selected, the check_host() function + parses and interprets it to find a result for the current test. If + there are any syntax errors, check_host() returns immediately with + the result "PermError". + + + +Wong & Schlitt Expires December 8, 2005 [Page 15] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + Implementations MAY choose to parse the entire record first and + return "PermError" if the record is not syntactically well formed. + However, in all cases, any syntax errors anywhere in the record MUST + be detected. + +4.6.1. Term Evaluation + + There are two types of terms: mechanisms and modifiers. A record + contains an ordered list of these as specified in the following ABNF. + + terms = *( 1*SP ( directive / modifier ) ) + + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" + mechanism = ( all / include + / A / MX / PTR / IP4 / IP6 / exists ) + modifier = redirect / explanation / unknown-modifier + unknown-modifier = name "=" macro-string + + name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) + + Most mechanisms allow a ":" or "/" character after the name. + + Modifiers always contain an equals ('=') character immediately after + the name, and before any ":" or "/" characters that may be part of + the macro-string. + + Terms that do not contain any of "=", ":" or "/" are mechanisms, as + defined in Section 5. + + As per the definition of the ABNF notation in [I-D.crocker-abnf- + rfc2234bis], mechanism and modifier names are case-insensitive. + +4.6.2. Mechanisms + + Each mechanism is considered in turn from left to right. If there + are no more mechanisms, the result is specified in Section 4.7. + + When a mechanism is evaluated, one of three things can happen: it can + match, it can not match, or it can throw an exception. + + If it matches, processing ends and the qualifier value is returned as + the result of that record. If it does not match, processing + continues with the next mechanism. If it throws an exception, + mechanism processing ends and the exception value is returned. + + The possible qualifiers, and the results they return are: + + + + +Wong & Schlitt Expires December 8, 2005 [Page 16] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + "+" Pass + "-" Fail + "~" SoftFail + "?" Neutral + + The qualifier is optional and defaults to "+". + + When a mechanism matches and the qualifier is "-", then a "Fail" + result is returned and the explanation string is computed as + described in Section 6.2. + + The specific mechanisms are described in Section 5. + +4.6.3. Modifiers + + Modifiers are not mechanisms: they do not return match or not-match. + Instead they provide additional information. While modifiers do not + directly affect the evaluation of the record, the "redirect" modifier + has an effect after all the mechanisms have been evaluated. + +4.7. Default Result + + If none of the mechanisms match and there is no "redirect" modifier, + then the check_host() returns a result of "Neutral", just as if + "?all" were specified as the last directive. If there is a + "redirect" modifier, check_host() proceeds as defined in Section 6.1. + + Note that records SHOULD always either use a "redirect" modifier or + an "all" mechanism to explicitly terminate processing. + + For example: + + v=spf1 +mx -all + or + v=spf1 +mx redirect=_spf.example.com + +4.8. Domain Specification + + Several of these mechanisms and modifiers have a <domain-spec> + section. The <domain-spec> string is macro expanded (see Section 8). + The resulting string is the common presentation form of a fully- + qualified DNS name: a series of labels separated by periods. This + domain is called the <target-name> in the rest of this document. + + Note: The result of the macro expansion is not subject to any further + escaping. Hence, this facility cannot produce all characters that + are legal in a DNS label (e.g. the control characters). However, + this facility is powerful enough to express legal host names, and + + + +Wong & Schlitt Expires December 8, 2005 [Page 17] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + common utility labels (such as "_spf") that are used in DNS. + + For several mechanisms, the <domain-spec> is optional. If it is not + provided, the <domain> is used as the <target-name>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 18] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +5. Mechanism Definitions + + This section defines two types of mechanisms. + + Basic mechanisms contribute to the language framework. They do not + specify a particular type of authorization scheme. + + all + include + + Designated sender mechanisms are used to designate a set of <ip> + addresses as being permitted or not permitted to use the <domain> for + sending mail. + + a + mx + ptr + ip4 + ip6 + exists + + The following conventions apply to all mechanisms that perform a + comparison between <ip> and an IP address at any point: + + If no CIDR-length is given in the directive, then <ip> and the IP + address are compared for equality. + + If a CIDR-length is specified, then only the specified number of + high-order bits of <ip> and the IP address are compared for equality. + + When any mechanism fetches host addresses to compare with <ip>, when + <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 + address, AAAA records are fetched. Even if the SMTP connection is + via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513] section + 2.5.5) MUST still be considered an IPv4 address. + + Several mechanisms rely on information fetched from DNS. For these + DNS queries, except where noted, if the DNS server returns an error + (RCODE other than 0 or 3) or the query times out, the mechanism + throws the exception "TempError". If the server returns "domain does + not exist" (RCODE 3), then evaluation of the mechanism continues as + if the server returned no error (RCODE 0) and zero answer records. + +5.1. "all" + + all = "all" + + The "all" mechanism is a test that always matches. It is used as the + + + +Wong & Schlitt Expires December 8, 2005 [Page 19] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + rightmost mechanism in a record to provide an explicit default. + + For example: + + v=spf1 a mx -all + + Mechanisms after "all" will never be tested. Any "redirect" modifier + (Section 6.1) has no effect when there is an "all" mechanism. + +5.2. "include" + + include = "include" ":" domain-spec + + The "include" mechanism triggers a recursive evaluation of + check_host(). The domain-spec is expanded as per Section 8. Then + check_host() is evaluated with the resulting string as the <domain>. + The <ip> and <sender> arguments remain the same as in the current + evaluation of check_host(). + + In hindsight, the name "include" was poorly chosen. Only the + evaluated result of the referenced SPF record is used, rather than + acting as if the referenced SPF record was literally included in the + first. For example, evaluating a "-all" directive in the referenced + record does not terminate the overall processing and does not + necessarily result in an overall "Fail". (Better names for this + mechanism would have been "if-pass", "on-pass", etc.) + + The "include" mechanism makes it possible for one domain to designate + multiple administratively-independent domains. For example, a vanity + domain "example.net" might send mail using the servers of + administratively-independent domains example.com and example.org. + + Example.net could say + + IN TXT "v=spf1 include:example.com include:example.org -all" + + This would direct check_host() to, in effect, check the records of + example.com and example.org for a "Pass" result. Only if the host + were not permitted for either of those domains would the result be + "Fail". + + Whether this mechanism matches, does not match, or throws an error, + depends on the result of the recursive evaluation of check_host(): + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 20] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + +---------------------------------+---------------------------------+ + | A recursive check_host() result | Causes the "include" mechanism | + | of: | to: | + +---------------------------------+---------------------------------+ + | Pass | match | + | | | + | Fail | not match | + | | | + | SoftFail | not match | + | | | + | Neutral | not match | + | | | + | TempError | throw TempError | + | | | + | PermError | throw PermError | + | | | + | None | throw PermError | + +---------------------------------+---------------------------------+ + + The "include" mechanism is intended for crossing administrative + boundaries. While it is possible to use includes to consolidate + multiple domains that share the same set of designated hosts, domains + are encouraged to use redirects where possible, and to minimize the + number of includes within a single administrative domain. For + example, if example.com and example.org were managed by the same + entity, and if the permitted set of hosts for both domains were + "mx:example.com", it would be possible for example.org to specify + "include:example.com", but it would be preferable to specify + "redirect=example.com" or even "mx:example.com". + +5.3. "a" + + This mechanism matches if <ip> is one of the <target-name>'s IP + addresses. + + A = "a" [ ":" domain-spec ] [ dual-cidr-length ] + + An address lookup is done on the <target-name>. The <ip> is compared + to the returned address(es). If any address matches, the mechanism + matches. + +5.4. "mx" + + This mechanism matches if <ip> is one of the MX hosts for a domain + name. + + MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] + + + + +Wong & Schlitt Expires December 8, 2005 [Page 21] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + check_host() first performs an MX lookup on the <target-name>. Then + it performs an address lookup on each MX name returned. The <ip> is + compared to each returned IP address. To prevent DoS attacks, more + than 10 MX names MUST NOT be looked up during the evaluation of an + "mx" mechanism (see Section 10). If any address matches, the + mechanism matches. + + Note regarding implicit MXes: If the <target-name> has no MX records, + check_host() MUST NOT pretend the target is its single MX, and MUST + NOT default to an A lookup on the <target-name> directly. This + behavior breaks with the legacy "implicit MX" rule. See [RFC2821] + Section 5. If such behavior is desired, the publisher should specify + an "a" directive. + +5.5. "ptr" + + This mechanism tests whether the DNS reverse mapping for <ip> exists + and correctly points to a domain name within a particular domain. + + PTR = "ptr" [ ":" domain-spec ] + + First the <ip>'s name is looked up using this procedure: perform a + DNS reverse-mapping for <ip>, looking up the corresponding PTR record + in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." + if it is an IPv6 address. For each record returned, validate the + domain name by looking up its IP address. To prevent DoS attacks, + more than 10 PTR names MUST NOT be looked up during the evaluation of + a "ptr" mechanism (see Section 10). If <ip> is among the returned IP + addresses, then that domain name is validated. In pseudocode: + + sending-domain_names := ptr_lookup(sending-host_IP); + if more than 10 sending-domain_names are found, use at most 10. + for each name in (sending-domain_names) { + IP_addresses := a_lookup(name); + if the sending-domain_IP is one of the IP_addresses { + validated-sending-domain_names += name; + } + } + + Check all validated domain names to see if they end in the + <target-name> domain. If any do, this mechanism matches. If no + validated domain name can be found, or if none of the validated + domain names end in the <target-name>, this mechanism fails to match. + If a DNS error occurs while doing the PTR RR lookup, then this + mechanism fails to match. If a DNS error occurs while doing an A RR + lookup, then that domain name is skipped and the search continues. + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 22] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + Pseudocode: + + for each name in (validated-sending-domain_names) { + if name ends in <domain-spec>, return match. + if name is <domain-spec>, return match. + } + return no-match. + + This mechanism matches if the <target-name> is either an ancestor of + a validated domain name, or if the <target-name> and a validated + domain name are the same. For example: "mail.example.com" is within + the domain "example.com", but "mail.bad-example.com" is not. + + Note: Use of this mechanism is discouraged because it is slow, is not + as reliable as other mechanisms in cases of DNS errors and it places + a large burden on the arpa name servers. If used, proper PTR records + must be in place for the domain's hosts and the "ptr" mechanism + should be one of the last mechanisms checked. + +5.6. "ip4" and "ip6" + + These mechanisms test whether <ip> is contained within a given IP + network. + + IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] + IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] + + ip4-cidr-length = "/" 1*DIGIT + ip6-cidr-length = "/" 1*DIGIT + dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] + + ip4-network = qnum "." qnum "." qnum "." qnum + qnum = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + ; as per conventional dotted quad notation. e.g. 192.0.2.0 + ip6-network = <as per [RFC 3513], section 2.2> + ; e.g. 2001:DB8::CD30 + + The <ip> is compared to the given network. If CIDR-length high-order + bits match, the mechanism matches. + + If ip4-cidr-length is omitted it is taken to be "/32". If + ip6-cidr-length is omitted it is taken to be "/128". It is not + permitted to omit parts of the IP address instead of using CIDR + notations. That is, use 192.0.2.0/24 instead of 192.0.2. + + + +Wong & Schlitt Expires December 8, 2005 [Page 23] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +5.7. "exists" + + This mechanism is used to construct an arbitrary domain name that is + used for a DNS A record query. It allows for complicated schemes + involving arbitrary parts of the mail envelope to determine what is + permitted. + + exists = "exists" ":" domain-spec + + The domain-spec is expanded as per Section 8. The resulting domain + name is used for a DNS A RR lookup. If any A record is returned, + this mechanism matches. The lookup type is 'A' even when the + connection type is IPv6. + + Domains can use this mechanism to specify arbitrarily complex + queries. For example, suppose example.com publishes the record: + + v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all + + The <target-name> might expand to + "1.2.0.192.someuser._spf.example.com". This makes fine-grained + decisions possible at the level of the user and client IP address. + + This mechanism enables queries that mimic the style of tests that + existing anti-spam DNS blacklists (DNSBL) use. + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 24] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +6. Modifier Definitions + + Modifiers are name/value pairs that provide additional information. + Modifiers always have an "=" separating the name and the value. + + The modifiers defined in this document ("redirect" and "exp") MAY + appear anywhere in the record, but SHOULD appear at the end, after + all mechanisms. Ordering of these two modifiers does not matter. + These two modifiers MUST NOT appear in a record more than once each. + If they do, then check_host() exits with a result of "PermError". + + Unrecognized modifiers MUST be ignored no matter where in a record, + or how often. This allows implementations of this document to + gracefully handle records with modifiers that are defined in other + specifications. + +6.1. redirect: Redirected Query + + If all mechanisms fail to match, and a "redirect" modifier is + present, then processing proceeds as follows: + + redirect = "redirect" "=" domain-spec + + The domain-spec portion of the redirect section is expanded as per + the macro rules in Section 8. Then check_host() is evaluated with + the resulting string as the <domain>. The <ip> and <sender> + arguments remain the same as current evaluation of check_host(). + + The result of this new evaluation of check_host() is then considered + the result of the current evaluation with the exception that if no + SPF record is found, or if the target-name is malformed, the result + is a "PermError" rather than "None". + + Note that the newly-queried domain may itself specify redirect + processing. + + This facility is intended for use by organizations that wish to apply + the same record to multiple domains. For example: + + la.example.com. TXT "v=spf1 redirect=_spf.example.com" + ny.example.com. TXT "v=spf1 redirect=_spf.example.com" + sf.example.com. TXT "v=spf1 redirect=_spf.example.com" + _spf.example.com. TXT "v=spf1 mx:example.com -all" + + In this example, mail from any of the three domains is described by + the same record. This can be an administrative advantage. + + Note: In general, the domain "A" cannot reliably use a redirect to + + + +Wong & Schlitt Expires December 8, 2005 [Page 25] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + another domain "B" not under the same administrative control. Since + the <sender> stays the same, there is no guarantee that the record at + domain "B" will correctly work for mailboxes in domain "A", + especially if domain "B" uses mechanisms involving localparts. An + "include" directive may be more appropriate. + + For clarity it is RECOMMENDED that any "redirect" modifier appear as + the very last term in a record. + +6.2. exp: Explanation + + explanation = "exp" "=" domain-spec + + If check_host() results in a "Fail" due to a mechanism match (such as + "-all"), and the "exp" modifier is present, then the explanation + string returned is computed as described below. If no "exp" modifier + is present, then either a default explanation string or an empty + explanation string may be returned. + + The <domain-spec> is macro expanded (see Section 8) and becomes the + <target-name>. The DNS TXT record for the <target-name> is fetched. + + If <domain-spec> is empty, or there are any DNS processing errors + (any RCODE other than 0), or if no records are returned, or if more + than one record is returned, or if there are syntax errors in the + explanation string, then proceed as if no exp modifier was given. + + The fetched TXT record's strings are concatenated with no spaces, and + then treated as an <explain-string> which is macro-expanded. This + final result is the explanation string. Implementations MAY limit + the length of the resulting explanation string to allow for other + protocol constraints and/or reasonable processing limits. Since the + explanation string is intended for an SMTP response and [RFC2821] + section 2.4 says that responses are in [US-ASCII], the explanation + string is also limited to US-ASCII. + + Software evaluating check_host() can use this string to communicate + information from the publishing domain in the form of a short message + or URL. Software SHOULD make it clear that the explanation string + comes from a third party. For example, it can prepend the macro + string "%{o} explains: " to the explanation, such as shown in + Section 2.5.4. + + Suppose example.com has this record: + + v=spf1 mx -all exp=explain._spf.%{d} + + Here are some examples of possible explanation TXT records at + + + +Wong & Schlitt Expires December 8, 2005 [Page 26] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + explain._spf.example.com: + "Mail from example.com should only be sent by its own servers." + -- a simple, constant message + + "%{i} is not one of %{d}'s designated mail servers." + -- a message with a little more info, including the IP address + that failed the check + + "See http://%{d}/why.html?s=%{S}&i=%{I}" + -- a complicated example that constructs a URL with the + arguments to check_host() so that a web page can be + generated with detailed, custom instructions + + Note: During recursion into an "include" mechanism, an exp= modifier + from the <target-name> MUST NOT be used. In contrast, when executing + a "redirect" modifier, an exp= modifier from the original domain MUST + NOT be used. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 27] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +7. The Received-SPF header field + + It is RECOMMENDED that SMTP receivers record the result of SPF + processing in the message headers. If an SMTP receiver chooses to do + so, it SHOULD use the "Received-SPF" header defined here for each + identity that was checked. This information is intended for the + recipient. (Information intended for the sender is described in + Section 6.2, Explanation.) + + The Received-SPF header is a trace field (see [RFC2822] section + 3.6.7) and SHOULD be prepended to existing headers, above the + Received: header that is generated by the SMTP receiver. It MUST + appear above any other Received-SPF headers in the message. The + header has the format: + + header = "Received-SPF:" [CFWS] result FWS [comment FWS] + [ key-value-list ] CRLF + + result = "Pass" / "Fail" / "SoftFail" / "Neutral" / + "None" / "TempError" / "PermError" + + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] + + key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) + + key = "client-ip" / "envelope-from" / "helo" / + "problem" / "receiver" / "identity" / + mechanism / "x-" name / name + + identity = "mailfrom" ; for the "MAIL FROM" identity + / "helo" ; for the "HELO" identity + / name ; other identities + + dot-atom = <unquoted word as per [RFC2822]> + quoted-string = <quoted string as per [RFC2822]> + comment = <comment string as per [RFC2822]> + CFWS = <comment or folding white space as per [RFC2822]> + FWS = <folding white space as per [RFC2822]> + CRLF = <standard end-of-line token as per [RFC2822]> + + The header SHOULD include a "(...)" style <comment> after the result, + conveying supporting information for the result, such as <ip>, + <sender> and <domain>. + + The following key-value pairs are designed for later machine parsing. + SPF clients SHOULD give enough information so that the SPF results + can be verified. That is, at least the "client-ip", "helo", and, if + + + +Wong & Schlitt Expires December 8, 2005 [Page 28] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + the "MAIL FROM" identity was checked, the "envelope-from". + + client-ip the IP address of the SMTP client + + envelope-from the envelope sender mailbox + + helo the host name given in the HELO or EHLO command + + mechanism the mechanism that matched (if no mechanisms matched, + substitute the word "default".) + + problem if an error was returned, details about the error + + receiver the host name of the SPF client + + identity the identity that was checked, see the <identity> ABNF + rule. + + Other keys may be defined by SPF clients. Until a new key name + becomes widely accepted, new key names should start with "x-". + + SPF clients MUST make sure that the Received-SPF header does not + contain invalid characters, is not excessively long, and does not + contain malicious data that has been provided by the sender. + + Examples of various header styles that could be generated: + + Received-SPF: Pass (mybox.example.org: domain of + myname@example.com designates 192.0.2.1 as permitted sender) + receiver=mybox.example.org; client-ip=192.0.2.1; + envelope-from=<myname@example.com>; helo=foo.example.com; + + + Received-SPF: Fail (mybox.example.org: domain of + myname@example.com does not designate + 192.0.2.1 as permitted sender) + identity=mailfrom; client-ip=192.0.2.1; + envelope-from=<myname@example.com>; + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 29] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +8. Macros + +8.1. Macro definitions + + Many mechanisms and modifiers perform macro expansion on part of the + term. + + domain-spec = macro-string domain-end + domain-end = ( "." toplabel ) / macro-expand + + toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum + ; LDH rule (See [RFC3696]) + alphanum = ALPHA / DIGIT + + explain-string = *( macro-string / SP ) + + macro-string = *( macro-expand / macro-literal ) + macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) + / "%%" / "%_" / "%-" + macro-literal = %x21-24 / %x26-7E + ; visible characters except "%" + macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / + "c" / "r" / "t" + transformers = *DIGIT [ "r" ] + delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" + + A literal "%" is expressed by "%%". + + "%_" expands to a single " " space. + "%-" expands to a URL-encoded space, viz. "%20". + + The following macro letters are expanded in term arguments: + + s = <sender> + l = local-part of <sender> + o = domain of <sender> + d = <domain> + i = <ip> + p = the validated domain name of <ip> + v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6 + h = HELO/EHLO domain + + The following macro letters are only allowed in "exp" text: + + c = SMTP client IP (easily readable format) + r = domain name of host performing the check + t = current timestamp + + + + +Wong & Schlitt Expires December 8, 2005 [Page 30] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + A '%' character not followed by a '{', '%', '-', or '_' character is + a syntax error. So, + + -exists:%(ir).sbl.spamhaus.example.org + + is incorrect and will cause check_host() to return a "PermError". + Instead, say + + -exists:%{ir}.sbl.spamhaus.example.org + + Optional transformers are: + + *DIGIT = zero or more digits + 'r' = reverse value, splitting on dots by default + + If transformers or delimiters are provided, the replacement value for + a macro letter is split into parts. After performing any reversal + operation and/or removal of left-hand parts, the parts are rejoined + using "." and not the original splitting characters. + + By default, strings are split on "." (dots). Note that no special + treatment is given to leading, trailing or consecutive delimiters, + and so the list of parts may contain empty strings. Macros may + specify delimiter characters which are used instead of ".". + + The 'r' transformer indicates a reversal operation: if the client IP + address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" + and the macro %{ir} would expand to "1.2.0.192". + + The DIGIT transformer indicates the number of right-hand parts to + use, after optional reversal. If a DIGIT is specified, the value + MUST be nonzero. If no DIGITs are specified, or if the value + specifies more parts than are available, all the available parts are + used. If the DIGIT was 5, and only 3 parts were available, the macro + interpreter would pretend the DIGIT was 3. Implementations MUST + support at least a value of 128, as that is the maximum number of + labels in a domain name. + + The "s" macro expands to the <sender> argument. It is an e-mail + address with a localpart, an "@" character, and a domain. The "l" + macro expands to just the localpart. The "o" macro expands to just + the domain part. Note that these values remain the same during + recursive and chained evaluations due to "include" and/or "redirect". + Note also that if the original <sender> had no localpart, the + localpart was set to "postmaster" in initial processing (see + Section 4.3). + + For IPv4 addresses, both the "i" and "c" macros expand to the + + + +Wong & Schlitt Expires December 8, 2005 [Page 31] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + standard dotted-quad format. + + For IPv6 addresses, the "i" macro expands to a dot-format address; it + is intended for use in %{ir}. The "c" macro may expand to any of the + hexadecimal colon-format addresses specified in [RFC3513] section + 2.2. It is intended for humans to read. + + The "p" macro expands to the validated domain name of <ip>. The + procedure for finding the validated domain name is defined in + Section 5.5. If the <domain> is present in the list of validated + domains, it SHOULD be used. Otherwise, if a subdomain of the + <domain> is present, it SHOULD be used. Otherwise, any name from the + list may be used. If there are no validated domain names or if a DNS + error occurs, the string "unknown" is used. + + The "r" macro expands to the name of the receiving MTA. This SHOULD + be a fully qualified domain name, but if one does not exist (as when + the checking is done by a MUA) or if policy restrictions dictate + otherwise, the word "unknown" SHOULD be substituted. The domain name + may be different than the name found in the MX record that the client + MTA used to locate the receiving MTA. + + The "t" macro expands to the decimal representation of the + approximate number of seconds since the Epoch (Midnight, January 1st, + 1970, UTC). This is the same value as is returned by the POSIX + time() function in most standards-compliant libraries. + + When the result of macro expansion is used in a domain name query, if + the expanded domain name exceeds 253 characters (the maximum length + of a domain name), the left side is truncated to fit, by removing + successive domain labels until the total length does not exceed 253 + characters. + + Uppercased macros expand exactly as their lower case equivalents, and + are then URL escaped. URL escaping must be performed for characters + not in the "uric" set, which is defined in [RFC3986]. + + Note: Care must be taken so that macro expansion for legitimate + e-mail does not exceed the 63 character limit on DNS labels. The + localpart of e-mail addresses, in particular, can have more than 63 + characters between dots. + + Note: Domains should avoid using the "s", "l", "o", or "h" macros in + conjunction with any mechanism directive. While these macros are + powerful and allow per-user records to be published, they severely + limit the ability of implementations to cache results of check_host() + and they reduce the effectiveness of DNS caches. + + + + +Wong & Schlitt Expires December 8, 2005 [Page 32] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + Implementations should be aware that if no directive processed during + the evaluation of check_host() contains an "s", "l", "o" or "h" + macro, then the results of the evaluation can be cached on the basis + of <domain> and <ip> alone for as long as the shortest TTL of all the + DNS records involved. + +8.2. Expansion Examples + + The <sender> is strong-bad@email.example.com. + The IPv4 SMTP client IP is 192.0.2.3. + The IPv6 SMTP client IP is 2001:DB8::CB01. + The PTR domain name of the client IP is mx.example.org. + + + macro expansion + ------- ---------------------------- + %{s} strong-bad@email.example.com + %{o} email.example.com + %{d} email.example.com + %{d4} email.example.com + %{d3} email.example.com + %{d2} example.com + %{d1} com + %{dr} com.example.email + %{d2r} example.email + %{l} strong-bad + %{l-} strong.bad + %{lr} strong-bad + %{lr-} bad.strong + %{l1r-} strong + + macro-string expansion + -------------------------------------------------------------------- + %{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com + %{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com + + %{lr-}.lp.%{ir}.%{v}._spf.%{d2} + bad.strong.lp.3.2.0.192.in-addr._spf.example.com + + %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} + 3.2.0.192.in-addr.strong.lp._spf.example.com + + %{d2}.trusted-domains.example.net + example.com.trusted-domains.example.net + + IPv6: + %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. + 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com + + + +Wong & Schlitt Expires December 8, 2005 [Page 33] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +9. Implications + + This section outlines the major implications that adoption of this + document will have on various entities involved in Internet e-mail. + It is intended to make clear to the reader where this document + knowingly affects the operation of such entities. This section is + not a "how-to" manual, nor a "best practices" document, and is not a + comprehensive list of what such entities should do in light of this + document. + + This section is non-normative. + +9.1. Sending Domains + + Domains that wish to be compliant with this specification will need + to determine the list of hosts that they allow to use their domain + name in the "HELO" and "MAIL FROM" identities. It is recognized that + forming such a list is not just a simple technical exercise, but + involves policy decisions with both technical and administrative + considerations. + + It can be helpful to publish records that include a "tracking + exists:" mechanism. By looking at the name server logs, a rough list + may then be generated. For example: + + v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all + +9.2. Mailing Lists + + Mailing lists must be aware of how they re-inject mail that is sent + to the list. Mailing lists MUST comply with the requirements in + [RFC2821] Section 3.10 and [RFC1123] Section 5.3.6 that say that the + reverse-path MUST be changed to be the mailbox of a person or other + entity who administers the list. While the reasons for changing the + reverse-path are many and long standing, SPF adds enforcement to this + requirement. + + In practice, almost all mailing list software in use already complies + with this requirement. Mailing lists that do not comply may or may + not encounter problems depending on how access to the list is + restricted. Such lists that are entirely internal to a domain (only + people in the domain can send to or receive from the list) are not + affected. + +9.3. Forwarding Services and Aliases + + Forwarding services take mail that is received at a mailbox and + direct it to some external mailbox. At the time of this writing, the + + + +Wong & Schlitt Expires December 8, 2005 [Page 34] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + near-universal practice of such services is to use the original "MAIL + FROM" of a message when re-injecting it for delivery to the external + mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" + rather than a "mail list". This means the external mailbox's MTA + sees all such mail in a connection from a host of the forwarding + service, and so the "MAIL FROM" identity will not, in general, pass + authorization. + + There are three places that techniques can be used to ameliorate this + problem. + + 1. The beginning, when e-mail is first sent. + + 1. "Neutral" results could be given for IP addresses that may be + forwarders, instead of "Fail" results. For example: + + "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" + + This would cause a lookup on an anti-spam DNS blocklist + (DNSBL) and cause a result of "Fail" only for e-mail coming + from listed sources. All other e-mail, including e-mail sent + through forwarders, would receive a "Neutral" result. By + checking the DNSBL after the known good sources, problems + with incorrect listing on the DNSBL are greatly reduced. + + 2. The "MAIL FROM" identity could have additional information in + the localpart that cryptographically identifies the mail as + coming from an authorized source. In this case, such an SPF + record could be used: + + "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" + + Then, a specialized DNS server can be set up to serve the + _spf_verify subdomain which validates the localpart. While + this requires an extra DNS lookup, this only happens when the + e-mail would otherwise be rejected as not coming from a known + good source. + + Note that due to the 63 character limit for domain labels, + this approach only works reliably if the localpart signature + scheme is guaranteed either to only produce localparts with a + maximum of 63 characters or to gracefully handle truncated + localparts. + + 3. Similarly, a specialized DNS server could be set up that will + rate-limit the e-mail coming from unexpected IP addresses. + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 35] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" + + 4. SPF allows the creation of per-user policies for special + cases. For example, the following SPF record and appropriate + wildcard DNS records can be used: + + "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" + + 2. The middle, when e-mail is forwarded. + + 1. Forwarding services can solve the problem by rewriting the + "MAIL FROM" to be in their own domain. This means that mail + bounced from the external mailbox will have to be re-bounced + by the forwarding service. Various schemes to do this exist + though they vary widely in complexity and resource + requirements on the part of the forwarding service. + + 2. Several popular MTAs can be forced from "alias" semantics to + "mailing list" semantics by configuring an additional alias + with "owner-" prepended to the original alias name (e.g. an + alias of "friends: george@example.com, fred@example.org" + would need another alias of the form "owner-friends: + localowner"). + + 3. The end, when e-mail is received. + + 1. If the owner of the external mailbox wishes to trust the + forwarding service, they can direct the external mailbox's + MTA to skip SPF tests when the client host belongs to the + forwarding service. + + 2. Tests against other identities, such as the "HELO" identity, + may be used to override a failed test against the "MAIL FROM" + identity. + + 3. For larger domains, it may not be possible to have a complete + or accurate list of forwarding services used by the owners of + the domain's mailboxes. In such cases, whitelists of + generally-recognized forwarding services could be employed. + +9.4. Mail Services + + Service providers that offer mail services to third-party domains, + such as sending of bulk mail, may have to adjust their setup in light + of the authorization check described in this document. If the "MAIL + FROM" identity used for such e-mail uses the domain of the service + provider, then the provider needs only to ensure that their sending + host is authorized by their own SPF record, if any. + + + +Wong & Schlitt Expires December 8, 2005 [Page 36] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + If the "MAIL FROM" identity does not use the mail service provider's + domain, then extra care must be taken. The SPF record format has + several options for the third party domain to authorize the service + provider's MTAs to send mail on its behalf. For mail service + providers, such as ISPs, that have a wide variety of customers using + the same MTA, steps should be taken to prevent cross-customer forgery + (see Section 10.4). + +9.5. MTA Relays + + The authorization check generally precludes the use of arbitrary MTA + relays between sender and receiver of an e-mail message. + + Within an organization, MTA relays can be effectively deployed. + However, for purposes of this document, such relays are effectively + transparent. The SPF authorization check is a check between border + MTAs of different domains. + + For mail senders, this means that published SPF records must + authorize any MTAs that actually send across the Internet. Usually, + these are just the border MTAs as internal MTAs simply forward mail + to these MTAs for delivery. + + Mail receivers will generally want to perform the authorization check + at the border MTAs, specifically including all secondary MXes. This + allows mail that fails to be rejected during the SMTP session rather + than bounced. Internal MTAs then do not perform the authorization + test. To perform the authorization test other than at the border, + the host that first transferred the message to the organization must + be determined, which can be difficult to extract from headers. + Testing other than at the border is not recommended. + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 37] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +10. Security Considerations + +10.1. Processing Limits + + As with most aspects of e-mail, there are a number of ways that + malicious parties could use the protocol as an avenue for a Denial- + of-Service (DoS) attack. The processing limits outlined here are + designed to prevent attacks such as: + + o A malicious party could create an SPF record with many references + to a victim's domain and send many e-mails to different SPF + clients; those SPF clients would then create a DoS attack. In + effect, the SPF clients are being used to amplify the attacker's + bandwidth by using fewer bytes in the SMTP session than are used + by the DNS queries. Using SPF clients also allows the attacker to + hide the true source of the attack. + + o While implementations of check_host() are supposed to limit the + number of DNS lookups, malicious domains could publish records + that exceed these limits in an attempt to waste computation effort + at their targets when they send them mail. Malicious domains + could also design SPF records that cause particular + implementations to use excessive memory or CPU usage, or to + trigger bugs. + + o Malicious parties could send a large volume of mail purporting to + come from the intended target to a wide variety of legitimate mail + hosts. These legitimate machines would then present a DNS load on + the target as they fetched the relevant records. + + Of these, the case of a third party referenced in the SPF record is + the easiest for a DoS attack to effectively exploit. As a result, + limits that may seem reasonable for an individual mail server can + still allow an unreasonable amount of bandwidth amplification. + Therefore the processing limits need to be quite low. + + SPF implementations MUST limit the number of mechanisms and modifiers + that do DNS lookups to at most 10 per SPF check, including any + lookups caused by the use of the "include" mechanism or the + "redirect" modifier. If this number is exceeded during a check, a + PermError MUST be returned. The "include", "a", "mx", "ptr", and + "exists" mechanisms as well as the "redirect" modifier do count + against this limit. The "all", "ip4" and "ip6" mechanisms do not + require DNS lookups and therefore do not count against this limit. + The "exp" modifier does not count against this limit because the DNS + lookup to fetch the explanation string occurs after the SPF record + has been evaluated. + + + + +Wong & Schlitt Expires December 8, 2005 [Page 38] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, + there MUST be a limit of no more than 10 MX or PTR RRs looked up and + checked. + + SPF implementations SHOULD limit the total amount of data obtained + from the DNS queries. For example, when DNS over TCP or EDNS0 are + available, there may need to be an explicit limit to how much data + will be accepted to prevent excessive bandwidth usage or memory + usage, and DoS attacks. + + MTAs or other processors MAY also impose a limit on the maximum + amount of elapsed time to evaluate check_host(). Such a limit SHOULD + allow at least 20 seconds. If such a limit is exceeded, the result + of authorization SHOULD be "TempError". + + Domains publishing records SHOULD try to keep the number of "include" + mechanisms and chained "redirect" modifiers to a minimum. Domains + SHOULD also try to minimize the amount of other DNS information + needed to evaluate a record. This can be done by choosing directives + that require less DNS information and placing lower-cost mechanisms + earlier in the SPF record. + + For example, consider a domain set up as: + + example.com. IN MX 10 mx.example.com. + mx.example.com. IN A 192.0.2.1 + a.example.com. IN TXT "v=spf1 mx:example.com -all" + b.example.com. IN TXT "v=spf1 a:mx.example.com -all" + c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" + + Evaluating check_host() for the domain "a.example.com" requires the + MX records for "example.com", and then the A records for the listed + hosts. Evaluating for "b.example.com" only requires the A records. + Evaluating for "c.example.com" requires none. + + However, there may be administrative considerations: using "a" over + "ip4" allows hosts to be renumbered easily. Using "mx" over "a" + allows the set of mail hosts to be changed easily. + +10.2. SPF-Authorized E-Mail May Be UBE + + The "MAIL FROM" and "HELO" identity authorizations must not be + construed to provide more assurance than they do. It is entirely + possible for a malicious sender to inject a message using their own + domain in the identities used by SPF, to have that domain's SPF + record authorize the sending host, and yet the message content can + easily claim other identities in the headers. Unless the user or the + MUA takes care to note that the authorized identity does not match + + + +Wong & Schlitt Expires December 8, 2005 [Page 39] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + the other more commonly-presented identities (such as the From: + header), the user may be lulled into a false sense of security. + +10.3. Spoofed DNS and IP Data + + There are two aspects of this protocol that malicious parties could + exploit to undermine the validity of the check_host() function: + + o The evaluation of check_host() relies heavily on DNS. A malicious + attacker could attack the DNS infrastructure and cause + check_host() to see spoofed DNS data, and then return incorrect + results. This could include returning "Pass" for an <ip> value + where the actual domain's record would evaluate to "Fail". See + [RFC3833] for a description of the DNS weaknesses. + + o The client IP address, <ip>, is assumed to be correct. A + malicious attacker could spoof TCP sequence numbers to make mail + appear to come from a permitted host for a domain that the + attacker is impersonating. + +10.4. Cross-User Forgery + + By definition, SPF policies just map domain names to sets of + authorized MTAs, not whole e-mail addresses to sets of authorized + users. Although the "l" macro (Section 8) provides a limited way to + define individual sets of authorized MTAs for specific e-mail + addresses, it is generally impossible to verify, through SPF, the use + of specific e-mail addresses by individual users of the same MTA. + + It is up to mail services and their MTAs to directly prevent cross- + user forgery: based on SMTP AUTH ([RFC2554]), users should be + restricted to using only those e-mail addresses that are actually + under their control (see [I-D.gellens-submit-bis] section 6.1). + Another means to verify the identity of individual users is message + cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]). + +10.5. Untrusted Information Sources + + SPF uses information supplied by third parties, such as the "HELO" + domain name, the "MAIL FROM" address, and SPF records. This + information is then passed to the receiver in the Received-SPF: mail + headers and possibly returned to the client MTA in the form of an + SMTP rejection message. This information must be checked for invalid + characters and excessively long lines. + + When the authorization check fails, an explanation string may be + included in the reject response. Both the sender and the rejecting + receiver need to be aware that the explanation was determined by the + + + +Wong & Schlitt Expires December 8, 2005 [Page 40] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + publisher of the SPF record checked and, in general, not the + receiver. The explanation may contain malicious URLs, or it may be + offensive or misleading. + + This is probably less of a concern than it may initially seem since + such messages are returned to the sender, and the explanation strings + come from the sender policy published by the domain in the identity + claimed by that very sender. As long as the DSN is not redirected to + someone other than the actual sender, the only people who see + malicious explanation strings are people whose messages claim to be + from domains that publish such strings in their SPF records. In + practice DSNs can be misdirected, such as when an MTA accepts an + e-mail and then later generates a DSN to a forged address, or when an + e-mail forwarder does not direct the DSN back to the original sender. + +10.6. Privacy Exposure + + Checking SPF records causes DNS queries to be sent to the domain + owner. These DNS queries, especially if they are caused by the + "exists" mechanism, can contain information about who is sending + e-mail and likely to which MTA the e-mail is being sent to. This can + introduce some privacy concerns, which may be more or less of an + issue depending on local laws and the relationship between the domain + owner and the person sending the e-mail. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 41] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +11. Contributors and Acknowledgements + + This document is largely based on the work of Meng Weng Wong and Mark + Lentczner. While, as this section acknowledges, many people have + contributed to this document, a very large portion of the writing and + editing are due to Meng and Mark. + + This design owes a debt of parentage to [RMX] by Hadmut Danisch and + to [DMP] by Gordon Fecyk. The idea of using a DNS record to check + the legitimacy of an e-mail address traces its ancestry farther back + through messages on the namedroppers mailing list by Paul Vixie + [Vixie] (based on suggestion by Jim Miller) and by David Green + [Green]. + + Philip Gladstone contributed the concept of macros to the + specification, multiplying the expressiveness of the language and + making per-user and per-IP lookups possible. + + The authors would also like to thank the literally hundreds of + individuals who have participated in the development of this design. + They are far too numerous to name, but they include: + + The folks on the spf-discuss mailing list. + The folks on the SPAM-L mailing list. + The folks on the IRTF ASRG mailing list. + The folks on the IETF MARID mailing list. + The folks on #perl. + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 42] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +12. IANA Considerations + +12.1. The SPF DNS Record Type + + The IANA needs to assign a new Resource Record Type and Qtype from + the DNS Parameters Registry for the SPF RR type. + +12.2. The Received-SPF mail header + + Per [RFC3864], the "Received-SPF:" header field is added to the IANA + Permanent Message Header Field Registry. The following is the + registration template: + + Header field name: Received-SPF + Applicable protocol: mail ([RFC2822]) + Status: standard + (Note to RFC Editor: Replace the status with the final + determination by the IESG) + Author/Change controller: IETF + Specification document(s): this Internet Draft + (Note to RFC Editor: Replace this with RFC YYYY (RFC number of + this spec)) + Related information: + Requesting SPF Council review of any proposed changes and + additions to this field is recommended. For information about SPF + Council see http://spf.mehnle.net/ + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 43] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +13. References + +13.1 Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [I-D.crocker-abnf-rfc2234bis] + Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 + (work in progress), March 2005. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format + for Delivery Status Notifications", RFC 3464, + January 2003. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [US-ASCII] + American National Standards Institute (formerly United + States of America Standards Institute), "USA Code for + Information Interchange, X3.4", 1968. + + ANSI X3.4-1968 has been replaced by newer versions with + slight modifications, but the 1968 version remains + definitive for the Internet. + + + + +Wong & Schlitt Expires December 8, 2005 [Page 44] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +13.2 Informative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, + August 1996. + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + [I-D.gellens-submit-bis] + Gellens, R. and J. Klensin, "Message Submission for Mail", + draft-gellens-submit-bis-02 (work in progress), + April 2005. + + [RFC2554] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [RFC3696] Klensin, J., "Application Techniques for Checking and + Transformation of Names", RFC 3696, February 2004. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail + Extensions (S/MIME) Version 3.1 Message Specification", + RFC 3851, July 2004. + + [RMX] Danish, H., "The RMX DNS RR Type for light weight sender + authentication", October 2003. + + Work In Progress + + [DMP] Fecyk, G., "Designated Mailers Protocol", December 2003. + + Work In Progress + + [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. + + [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 45] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +Appendix A. Collected ABNF + + This section is normative and any discrepancies with the ABNF + fragments in the preceding text are to be resolved in favor of this + grammar. + + See [I-D.crocker-abnf-rfc2234bis] for ABNF notation. Please note + that as per this ABNF definition, literal text strings (those in + quotes) are case-insensitive. Hence, "mx" matches "mx", "MX", "mX" + and "Mx". + + record = version terms *SP + version = "v=spf1" + + terms = *( 1*SP ( directive / modifier ) ) + + directive = [ qualifier ] mechanism + qualifier = "+" / "-" / "?" / "~" + mechanism = ( all / include + / A / MX / PTR / IP4 / IP6 / exists ) + + all = "all" + include = "include" ":" domain-spec + A = "a" [ ":" domain-spec ] [ dual-cidr-length ] + MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] + PTR = "ptr" [ ":" domain-spec ] + IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] + IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] + exists = "exists" ":" domain-spec + + modifier = redirect / explanation / unknown-modifier + redirect = "redirect" "=" domain-spec + explanation = "exp" "=" domain-spec + unknown-modifier = name "=" macro-string + + ip4-cidr-length = "/" 1*DIGIT + ip6-cidr-length = "/" 1*DIGIT + dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] + + ip4-network = qnum "." qnum "." qnum "." qnum + qnum = DIGIT ; 0-9 + / %x31-39 DIGIT ; 10-99 + / "1" 2DIGIT ; 100-199 + / "2" %x30-34 DIGIT ; 200-249 + / "25" %x30-35 ; 250-255 + ; conventional dotted quad notation. e.g. 192.0.2.0 + ip6-network = <as per [RFC 3513], section 2.2> + ; e.g. 2001:DB8::CD30 + + + +Wong & Schlitt Expires December 8, 2005 [Page 46] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + domain-spec = macro-string domain-end + domain-end = ( "." toplabel ) / macro-expand + toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum + ; LDH rule (See [RFC3696]) + alphanum = ALPHA / DIGIT + + explain-string = *( macro-string / SP ) + + macro-string = *( macro-expand / macro-literal ) + macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) + / "%%" / "%_" / "%-" + macro-literal = %x21-24 / %x26-7E + ; visible characters except "%" + macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / + "c" / "r" / "t" + transformers = *DIGIT [ "r" ] + delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" + + name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) + + header = "Received-SPF:" [CFWS] result FWS [comment FWS] + [ key-value-list ] CRLF + + result = "Pass" / "Fail" / "SoftFail" / "Neutral" / + "None" / "TempError" / "PermError" + + key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) + [";"] + + key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) + + key = "client-ip" / "envelope-from" / "helo" / + "problem" / "receiver" / "identity" / + mechanism / "x-" name / name + + identity = "mailfrom" ; for the "MAIL FROM" identity + / "helo" ; for the "HELO" identity + / name ; other identities + + dot-atom = <unquoted word as per [RFC2822]> + quoted-string = <quoted string as per [RFC2822]> + comment = <comment string as per [RFC2822]> + CFWS = <comment or folding white space as per [RFC2822]> + FWS = <folding white space as per [RFC2822]> + CRLF = <standard end-of-line token as per [RFC2822]> + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 47] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +Appendix B. Extended Examples + + These examples are based on the following DNS setup: + + ; A domain with two mail servers, two hosts + ; and two servers at the domain name + $ORIGIN example.com. + @ MX 10 mail-a + MX 20 mail-b + A 192.0.2.10 + A 192.0.2.11 + amy A 192.0.2.65 + bob A 192.0.2.66 + mail-a A 192.0.2.129 + mail-b A 192.0.2.130 + www CNAME example.com. + + ; A related domain + $ORIGIN example.org. + @ MX 10 mail-c + mail-c A 192.0.2.140 + + ; The reverse IP for those addresses + $ORIGIN 2.0.192.in-addr.arpa. + 10 PTR example.com. + 11 PTR example.com. + 65 PTR amy.example.com. + 66 PTR bob.example.com. + 129 PTR mail-a.example.com. + 130 PTR mail-b.example.com. + 140 PTR mail-c.example.org. + + ; A rogue reverse IP domain that claims to be + ; something it's not + $ORIGIN 0.0.10.in-addr.arpa. + 4 PTR bob.example.com. + +B.1. Simple Examples + + These examples show various possible published records for + example.com and which values if <ip> would cause check_host() to + return "Pass". Note that <domain> is "example.com". + + v=spf1 +all + -- any <ip> passes + + v=spf1 a -all + -- hosts 192.0.2.10 and 192.0.2.11 pass + + + +Wong & Schlitt Expires December 8, 2005 [Page 48] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + v=spf1 a:example.org -all + -- no sending hosts pass since example.org has no A records + + v=spf1 mx -all + -- sending hosts 192.0.2.129 and 192.0.2.130 pass + + v=spf1 mx:example.org -all + -- sending host 192.0.2.140 passes + + v=spf1 mx mx:example.org -all + -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass + + v=spf1 mx/30 mx:example.org/30 -all + -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes + + v=spf1 ptr -all + -- sending host 192.0.2.65 passes (reverse DNS is valid and is in + example.com) + -- sending host 192.0.2.140 fails (reverse DNS is valid, but not + in example.com) + -- sending host 10.0.0.4 fails (reverse IP is not valid) + + v=spf1 ip4:192.0.2.128/28 -all + -- sending host 192.0.2.65 fails + -- sending host 192.0.2.129 passes + +B.2. Multiple Domain Example + + These examples show the effect of related records: + + example.org: "v=spf1 include:example.com include:example.net -all" + + This record would be used if mail from example.org actually came + through servers at example.com and example.net. Example.org's + designated servers are the union of example.com's and example.net's + designated servers. + + la.example.org: "v=spf1 redirect=example.org" + ny.example.org: "v=spf1 redirect=example.org" + sf.example.org: "v=spf1 redirect=example.org" + + These records allow a set of domains that all use the same mail + system to make use of that mail system's record. In this way, only + the mail system's record needs to be updated when the mail setup + changes. These domains' records never have to change. + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 49] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +B.3. DNSBL Style Example + + Imagine that, in addition to the domain records listed above, there + are these: + + $ORIGIN _spf.example.com. + mary.mobile-users A 127.0.0.2 + fred.mobile-users A 127.0.0.2 + 15.15.168.192.joel.remote-users A 127.0.0.2 + 16.15.168.192.joel.remote-users A 127.0.0.2 + + The following records describe users at example.com who mail from + arbitrary servers, or who mail from personal servers. + + example.com: + + v=spf1 mx + include:mobile-users._spf.%{d} + include:remote-users._spf.%{d} + -all + + mobile-users._spf.example.com: + + v=spf1 exists:%{l1r+}.%{d} + + remote-users._spf.example.com: + + v=spf1 exists:%{ir}.%{l1r+}.%{d} + +B.4. Multiple Requirements Example + + Say that your sender policy requires that both the IP address is + within a certain range and that the reverse DNS for the IP matches. + This can be done several ways, including: + + example.com. SPF ( "v=spf1 " + "-include:ip4._spf.%{d} " + "-include:ptr._spf.%{d} " + "+all" ) + ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" + ptr._spf.example.com. SPF "v=spf1 -ptr +all" + + This example shows how the "-include" mechanism can be useful, how an + SPF record that ends in "+all" can be very restrictive and the use of + De Morgan's Law. + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 50] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +Appendix C. Change Log + + RFC Editor Note: This section is to be removed during the final + publication of the document. + +C.1. Changes in Version -02 + + o The abstract notes that SPF-classic covers both the HELO and MAIL + FROM identities. (ietf-822 review) + + o In section 2.3 "Publishing Authorization", it now makes it clear + that publishing is optional. (ietf-smtp review) + + o The definition of the "SoftFail" result have been recast from + Receiver Policy to Sender Policy. + + o The definitions of Neutral, Pass and PermError have been updated/ + clarified to more correctly reflect the semantics of + draft-mengwong-spf-01. + + o A note to the RFC editor was made indicating that the SPF DNS RR + type number should be added to the draft once the IANA has made an + allocation. + + o The ip4-network ABNF has been fixed to give the ABNF of the + dotted-quad format, rather than just using words to explain it. + + o The ABNF for the Received-SPF header now shows that it ends with a + CRLF. (ietf-822 review) + + o The new, optional, "scope" keyword-value pair has been renamed to + "identity". + + o The "exp=" modifier no longer counts toward the DoS DNS lookup + limits. + + o In section 10.5 "Untrusted Information Sources", the explanation + about explanation strings going to only the sender has been fixed + to note that, in some cases, it can go to other people. (ietf-822 + review) + + o Sections 3.1.2 and 3.1.3 were updated to make the distinction + between "multiple TXT RRs" and "multiple strings within a TXT" + clearer. (ietf-822 review) + + o A normative reference to US-ASCII has been added. + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 51] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + o Text describing how to lookup and process the SPF records has been + removed from section 3.1.1 "DNS Resource Record Types" and merged + into similar text in sections 4.4 "Record Lookup" and 4.5 + "Selecting Records" + + o Section 4.5 "Selecting Records" has been updated to give an + algorithm that says to return a PermError when it discovers that + SPF and TXT records don't match. + + o In section 6.1 "redirect: Redirected Query", the semantics have + been changed to specify a result of PermError instead of None in + cases where the target domain does not have any SPF records. It + makes no sense to return None, that is "no SPF records found", + when SPF records were found. + + o In section 6.2 "exp: Explanation", it is explained that the record + must be in US-ASCII due to requirements of RFC2821. + + o In section 6.2 "exp: Explanation", the duplicate warning about + source being from a third party was deleted. + + o A note has been added to section 9.3.1.2 warning about domain + labels being over 63 characters. + + o The "prefix" ABNF rule was renamed to "qualifier" to reflect the + semantics of the rule, rather than the syntax. + +C.2. Changes in Version -01 + + o IETF boilerplate was updated to BCP 79. + + o A version number was added to the title. (IESG review) + + o Many grammatical, typographical and spelling errors were + corrected, along with rephrasing sentences to make the intent and + meaning clearer. + + o Sections have been re-ordered in so that they conform to the + instructions2authors.txt document. All required sections and + arrangements are included, and only the "Security Considerations" + section is not in the suggested order. Since the Security + Considerations is such an important part of the spec, it has been + moved before the Acknowledgement section. + + o The HELO identity checking has been changed from "MAY" to + "RECOMMENDED". + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 52] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + o The e-mail receiver policy definition on how to handle HELO + checking was removed. It was copied incorrectly from + draft-mengwong-spf-01, changing its meaning. + + o A note was added that when changing SPF records, there needs to be + a transitional period to prevent incorrect results. + + o The RECOMMENDATION not to use other identities with version 1 SPF + records has been clarified. Example cases where checking other + identities will cause incorrect results have been cited. (IESG + review) + + o The "zone cut" method of determining if there is an SPF record at + the top of the zone has been removed. It wasn't implemented very + often and could not always be easily done. (IESG/namedroppers' + review) + + o A note was added that receivers should consider rejecting e-mail + for non-existent domains in order to prevent circumvention of SPF + policies. This is due to the remove of "zone cuts". + (namedroppers' review) + + o The RECOMMENDATION to perform SPF checks during the SMTP session + has been clarified and strengthened. + + o Note added about the consequences of treating "Neutral" results + worse than "None". + + o The suggested e-mail receiver policy when a "PermError" is + encountered has been changed to be, effectively, the same + semantics as were in draft-mengwong-spf-01. (MAAWG review) + + o ABNF cleaned up to pass Bill Fenner's checker and not just the one + at http://www.apps.ietf.org/abnf.html + + o A few host names/IP addresses were fixed to use appropriate ones + for I-Ds. + + o A definition of what to should be done if there are syntax errors + in the explanation string was added. (E.g. use the default.) + + o Section 10 "Security Considerations" has been broken up into + subsections and reorganized. + + o Section 7.1 "Process Limits" has been merged into the similar + language in the "Security Considerations" section. + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 53] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + + o The ABNF for the Received-SPF e-mail header has been made to be + more compatible with draft-mengwong-spf-01. It was fixed to + require whitespace when needed and to show where the suggested + comment should be added to the header. + + o The IANA Considerations section now has the required information + to document the Received-SPF header. + + o A new, optional, "scope" keyword has added to the Received-SPF + header. + + o The non-normative Section 9.3 "Forwarding Services and Aliases" + has been expanded to more thoroughly cover the subject. + + o New Security Considerations sections on "Privacy Exposure" and + "Cross-User Forgery" have been added. + + o A new example of an SPF policy with a non-obvious implementation + has been added. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 54] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +Authors' Addresses + + Meng Weng Wong + Singapore + + Email: mengwong+spf@pobox.com + URI: http://spf.pobox.com/ + + + Wayne Schlitt + 4615 Meredeth #9 + Lincoln Nebraska, NE 68506 + United States of America + + Email: wayne@schlitt.net + URI: http://www.schlitt.net/spf/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wong & Schlitt Expires December 8, 2005 [Page 55] + +Internet-Draft Sender Policy Framework (SPF) June 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Wong & Schlitt Expires December 8, 2005 [Page 56] + |
