diff options
Diffstat (limited to 'doc/draft')
49 files changed, 40278 insertions, 0 deletions
diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt new file mode 100644 index 0000000..1030e57 --- /dev/null +++ b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt @@ -0,0 +1,336 @@ + + + + +Internet-Draft T. Baba +Expires: March 11, 2004 NTT Data + September 11, 2003 + + + Requirements for Access Control in Domain Name Systems + draft-baba-dnsext-acl-reqts-01.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Distribution of this memo is unlimited. + + This Internet-Draft will expire on March 11, 2004. + +Abstract + + This document describes the requirements for access control + mechanisms in the Domain Name System (DNS), which authenticate + clients and then allow or deny access to resource records in the + zone according to the access control list (ACL). + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for bi-directional mapping between domain + names and IP addresses, for email routing, and for other information + [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined + to authenticate the data in DNS and provide key distribution services + using SIG, KEY, and NXT resource records (RRs) [RFC2535]. + + + +Baba Expires March 11, 2004 [Page 1] + +Internet-Draft DNS Access Control Requirements September 2003 + + + At the 28th IETF Meeting in Houston in 1993, DNS security design team + started a discussion about DNSSEC and agreed to accept the assumption + that "DNS data is public". Accordingly, confidentiality for queries + or responses is not provided by DNSSEC, nor are any sort of access + control lists or other means to differentiate inquirers. However, + about ten years has passed, access control in DNS has been more + important than before. Currently, new RRs are proposed to add new + functionality to DNS such as ENUM [RFC2916]. Such new RRs may + contain private information. Thus, DNS access control will be + needed. + + Furthermore, with DNS access control mechanism, access from + unauthorized clients can be blocked when they perform DNS name + resolution. Thus, for example, Denial of Service (DoS) attacks + against a server used by a closed user group can be prevented using + this mechanism if IP address of the server is not revealed by other + sources. + + This document describes the requirements for access control + mechanisms in DNS. + +2. Terminology + + AC-aware client + This is the client that understands the DNS access control + extensions. This client may be an end host which has a stub + resolver, or a cashing/recursive name server which has a + full-service resolver. + + AC-aware server + This is the authoritative name server that understands the DNS + access control extensions. + + ACE + An Access Control Entry. This is the smallest unit of access + control policy. It grants or denies a given set of access + rights to a set of principals. An ACE is a component of an ACL, + which is associated with a resource. + + ACL + An Access Control List. This contains all of the access control + policies which are directly associated with a particular + resource. These policies are expressed as ACEs. + + Client + A program or host which issues DNS requests and accepts its + responses. A client may be an end host or a cashing/recursive name + server. + + + +Baba Expires March 11, 2004 [Page 2] + +Internet-Draft DNS Access Control Requirements September 2003 + + + RRset + All resource records (RRs) having the same NAME, CLASS and TYPE + are called a Resource Record Set (RRset). + +3. Requirements + + This section describes the requirements for access control in DNS. + +3.1 Authentication + +3.1.1 Client Authentication Mechanism + + The AC-aware server must identify AC-aware clients based on IP + address and/or domain name (user ID or host name), and must + authenticate them using strong authentication mechanism such as + digital signature or message authentication code (MAC). + + SIG(0) RR [RFC2931] contains a domain name associated with sender's + public key in its signer's name field, and TSIG RR [RFC2845] also + contains a domain name associated with shared secret key in its key + name field. Each of these domain names can be a host name or a user + name, and can be used as a sender's identifier for access control. + Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for + message authentication. These mechanisms can be used to authenticate + AC-aware clients. + + Server authentication may be also provided. + +3.1.2 End-to-End Authentication + + In current DNS model, caching/recursive name servers are deployed + between end hosts and authoritative name servers. Although + authoritative servers can authenticate caching/recursive name servers + using SIG(0) or TSIG, they cannot authenticate end hosts behind them. + For end-to-end authentication, the mechanism for an end host to + discover the target authoritative name server and directly access to + it bypassing caching/recursive name servers is needed. For example, + an end host can get the IP addresses of the authoritative name + servers by retrieving NS RRs for the zone via local caching/recursive + name server. + + In many enterprise networks, however, there are firewalls that block + all DNS packets other than those going to/from the particular + caching/recursive servers. To deal with this problem, one can + implement packet forwarding function on the caching/recursive servers + and enable end-to-end authentication via the caching/recursive + servers. + + + + +Baba Expires March 11, 2004 [Page 3] + +Internet-Draft DNS Access Control Requirements September 2003 + + +3.1.3 Authentication Key Retrieval + + Keys which are used to authenticate clients should be able to be + automatically retrieved. The KEY RR is used to store a public key + for a zone or a host that is associated with a domain name. SIG(0) + RR uses a public key in KEY RR for verifying the signature. If + DNSSEC is available, the KEY RR would be protected by the SIG RR. + KEY RR or newly defined RR can be used to automatic key retrieval. + +3.2 Confidentiality + +3.2.1 Data Encryption + + To avoid disclosure to eavesdroppers, the response containing the + RRsets which are restricted to access from particular users should be + encrypted. Currently, no encryption mechanism is specified in DNS. + Therefore, new RRs should be defined for DNS message encryption. + Instead, IPsec [RFC2401] can be used to provide confidentiality if + name server and resolver can set up security associations dynamically + using IPsec API [IPSECAPI] when encryption is required. + + In case encryption is applied, entire DNS message including DNS + header should be encrypted to hide information including error code. + + Query encryption may be also provided for hiding query information. + +3.2.2 Key Exchange + + If DNS message encryption is provided, automatic key exchange + mechanism should be also provided. [RFC2930] specifies a TKEY RR + that can be used to establish and delete shared secret keys used by + TSIG between a client and a server. With minor extensions, TKEY can + be used to establish shared secret keys used for message encryption. + +3.2.3 Caching + + The RRset that is restricted to access from particular users must not + be cached. To avoid caching, the TTL of the RR that is restricted to + access should be set to zero during transit. + +3.3 Access Control + +3.3.1 Granularity of Access Control + + Control of access on a per-user/per-host granularity must be + supported. Control of access to individual RRset (not just the + entire zone) must be also supported. However, SOA, NS, SIG, NXT, + KEY, and DS RRs must be publicly accessible to avoid unexpected + results. + + +Baba Expires March 11, 2004 [Page 4] + +Internet-Draft DNS Access Control Requirements September 2003 + + +3.3.2 ACL Representation + + Access Control List (ACL) format must be standardized so that both + the primary and secondary AC-aware servers can recognize the same + ACL. Although ACL may appear in or out of zone data, it must be + transferred to the secondary AC-aware server with associated zone + data. It is a good idea to contain ACL in zone data, because ACL can + be transferred with zone data using existing zone transfer mechanisms + automatically. However, ACL must not be published except for + authorized secondary master servers. + + In zone data master files, ACL should be specified using TXT RRs or + newly defined RRs. In each access control entry (ACE), authorized + entities (host or user) must be described using domain name (host + name, user name, or IP address in in-addr.arpa/ip6.arpa format). + There may be other access control attributes such as access time. + + It must be possible to create publicly readable entries, which may be + read even by unauthenticated clients. + +3.3.3 Zone/ACL Transfer + + As mentioned above, ACL should be transferred from a primary AC-aware + server to a secondary AC-aware server with associated zone data. + When an AC-aware server receives a zone/ACL transfer request, the + server must authenticate the client, and should encrypt the zone + data and associated ACL during transfer. + +3.4 Backward/co-existence Compatibility + + Any new protocols to be defined for access control in DNS must be + backward compatible with existing DNS protocol. AC-aware servers + must be able to process normal DNS query without authentication, and + must respond if retrieving RRset is publicly accessible. + + Modifications to root/gTLD/ccTLD name servers are not allowed. + +4. Security Considerations + + This document discusses the requirements for access control + mechanisms in DNS. + +5. Acknowledgements + + This work is funded by the Telecommunications Advancement + Organization of Japan (TAO). + + The author would like to thank the members of the NTT DATA network + security team for their important contribution to this work. + + +Baba Expires March 11, 2004 [Page 5] + +Internet-Draft DNS Access Control Requirements September 2003 + + +6. References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, + September 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API", + draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in + Progress. + + +Author's Address + + Tatsuya Baba + NTT Data Corporation + Research and Development Headquarters + Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku, + Tokyo 104-0033, Japan + + Tel: +81 3 3523 8081 + Fax: +81 3 3523 8090 + Email: babatt@nttdata.co.jp + + + + + + + + +Baba Expires March 11, 2004 [Page 6] diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt new file mode 100644 index 0000000..fffa8a5 --- /dev/null +++ b/doc/draft/draft-daigle-napstr-04.txt @@ -0,0 +1,1232 @@ + + +Network Working Group L. Daigle +Internet-Draft A. Newton +Expires: August 15, 2004 VeriSign, Inc. + February 15, 2004 + + + Domain-based Application Service Location Using SRV RRs and the + Dynamic Delegation Discovery Service (DDDS) + draft-daigle-napstr-04.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo defines a generalized mechanism for application service + naming that allows service location without relying on rigid domain + naming conventions (so-called name hacks). The proposal defines a + Dynamic Delegation Discovery System (DDDS) Application to map domain + name, application service name, and application protocol to target + server and port, dynamically. + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 1] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4 + 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5 + 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5 + 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5 + 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5 + 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6 + 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6 + 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1 Guidelines for Application Protocol Developers . . . . . . . 7 + 3.1.1 Registration of application service and protocol tags . . . 7 + 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8 + 3.1.3 Server identification and handshake . . . . . . . . . . . . 8 + 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8 + 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9 + 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10 + 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10 + 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12 + 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12 + 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14 + 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15 + 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + A. Application Service Location Application of DDDS . . . . . . 18 + A.1 Application Unique String . . . . . . . . . . . . . . . . . 18 + A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18 + A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18 + A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19 + A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19 + A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20 + A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20 + A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20 + B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20 + B.1 Finding the first (best) target . . . . . . . . . . . . . . 20 + B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 + + + + +Daigle & Newton Expires August 15, 2004 [Page 2] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +1. Introduction + + This memo defines a generalized mechanism for application service + naming that allows service location without relying on rigid domain + naming conventions (so-called name hacks). The proposal defines a + Dynamic Delegation Discovery System (DDDS -- see [6]) Application to + map domain name, application service name, and application protocol + to target server and port, dynamically. + + As discussed in Section 5, existing approaches to using DNS records + to dynamically determining the current host for a given application + service are limited in terms of the use cases supported. To address + some of the limitations, this document defines a DDDS Application to + map service+protocol+domain to specific server addresses using both + NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as + a more general version of the use of SRV and/or a very restricted + application of the use of NAPTR resource records. + + 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]). + +2. Straightforward-NAPTR (S-NAPTR) Specification + + The precise details of the specification of this DDDS application are + given in Appendix A. This section defines the usage of the DDDS + application. + +2.1 Key Terms + + An "application service" is a generic term for some type of + application, indpendent of the protocol that may be used to offer it. + Each application service will be associated with an IANA-registered + tag. For example, instant messaging is a type of application + service, which can be implemented by many different application-layer + protocols, and the tag "IM" (used as an illustration here) could be + registered for it. + + An "application protocol" is used to implement the application + service. These are also associated with IANA-registered tags. In + the case where multiple transports are available for the application, + separate tags should be defined for each transport. + + The intention is that the combination of application service and + protocol tags should be specific enough that finding a known pair + (e.g., "IM:ProtC") is sufficient for a client to identify a server + with which it can communicate. + + + + +Daigle & Newton Expires August 15, 2004 [Page 3] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + Some protocols support multiple application services. For example, + LDAP is an application protocol, and can be found supporting various + services (e.g., "whitepages", "directory enabled networking", etc). + +2.2 S-NAPTR DDDS Application Usage + + As outlined in Appendix A, NAPTR records are used to store + application service+protocol information for a given domain. + Following the DDDS standard, these records are looked up, and the + rewrite rules (contained in the NAPTR records) are used to determine + the successive DNS lookups, until a desirable target is found. + + For the rest of this section, refer to the set of NAPTR resource + records for example.com shown in the figure below. + + example.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example. + IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com. + IN NAPTR 200 10 "" "IM:protA" "" someisp.example. + IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com. + + +2.2.1 Ordering and Preference + + A client retrieves all of the NAPTR records associated with the + target domain name (example.com, above). These are to be sorted in + terms of increasing ORDER, and increasing PREF within each ORDER. + +2.2.2 Matching and non-Matching NAPTR Records + + Starting with the first sorted NAPTR record, the client examines the + SERVICE field to find a match. In the case of the S-NAPTR DDDS + application, that means a SERVICE field that includes the tags for + the desired application service and a supported application protocol. + + If more than one NAPTR record matches, they are processed in + increasing sort order. + +2.2.3 Terminal and Non-Terminal NAPTR Records + + A NAPTR record with an empty FLAG field is "non-terminal". That is, + more NAPTR RR lookups are to be performed. Thus, to process a NAPTR + record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is + used as the target of the next DNS lookup -- for NAPTR RRs. + + In S-NAPTR, the only terminal flags are "S" and "A". These are + called "terminal" NAPTR lookups because they denote the end of the + + + +Daigle & Newton Expires August 15, 2004 [Page 4] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + DDDS/NAPTR processing rules. In the case of an "S" flag, the + REPLACEMENT field is used as the target of a DNS query for SRV RRs, + and normal SRV processing is applied. In the case of an "A" flag, an + address record is sought for the REPLACEMENT field target (and the + default protocol port is assumed). + +2.2.4 S-NAPTR and Successive Resolution + + As shown in the example NAPTR RR set above, it is possible to have + multiple possible targets for a single application service+protocol + pair. These are to be pursued in order until a server is + successfully contacted or all possible matching NAPTR records have + been successively pursued to terminal lookups and servers contacted. + That is, a client must backtrack and attempt other resolution paths + in the case of failure. + + "Failure" is declared, and backtracking must be used when + + o the designated remote server (host and port) fail to provide + appropriate security credentials for the *originating* domain + + o connection to the designated remote server otherwise fails -- the + specifics terms of which are defined when an application protocol + is registered + + o the S-NAPTR-designated DNS lookup fails to yield expected results + -- e.g., no A RR for an "A" target, no SRV record for an "S" + target, or no NAPTR record with appropriate application service + and protocol for a NAPTR lookup. Except in the case of the very + first NAPTR lookup, this last is a configuration error: the fact + that example.com has a NAPTR record pointing to "bunyip.example" + for the "WP:Whois++" service and protocol means the administrator + of example.com believes that service exists. If bunyip.example + has no "WP:Whois++" NAPTR record, the application client MUST + backtrack and try the next available "WP:Whois++" option from + example.com. As there is none, the whole resolution fails. + + An application client first queries for the NAPTR RRs for the domain + of a named application service. The application client MUST select + one protocol to choose The PREF field of the NAPTR RRs may be used by + the domain administrator to The first DNS query is for the NAPTR RRs + in the original target domain (example.com, above). + +2.2.5 Clients Supporting Multiple Protocols + + In the case of an application client that supports more than one + protocol for a given application service, it MUST pursue S-NAPTR + resolution completely for one protocol before trying another.j It MAY + + + +Daigle & Newton Expires August 15, 2004 [Page 5] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + choose which protocol to try first based on its own preference, or + from the PREF ranking in the first set of NAPTR records (i.e., those + for the target named domain). However, the chosen protocol MUST be + listed in that first NAPTR RR set. + + That is, what the client MUST NOT do is start looking for one + protocol, observe that a successive NAPTR RR set supports another of + its preferred protocols, and continue the S-NAPTR resolution based on + that protocol. For example, even if someisp.example offers the "IM" + service with protocol "ProtB", there is no reason to believe it does + so on behalf of example.com (since there is no such pointer in + example.com's NAPTR RR set). + +3. Guidelines + +3.1 Guidelines for Application Protocol Developers + + The purpose of S-NAPTR is to provide application standards developers + with a more powerful framework (than SRV RRs alone) for naming + service targets, without requiring each application protocol (or + service) standard to define a separate DDDS application. + + Note that this approach is intended specifically for use when it + makes sense to associate services with particular domain names (e.g., + e-mail addresses, SIP addresses, etc). A non-goal is having all + manner of label mapped into domain names in order to use this. + + Specifically not addressed in this document is how to select the + domain for which the service+protocol is being sought. It is up to + other conventions to define how that might be used (e.g., instant + messaging standards can define what domain to use from IM URIs, how + to step down from foobar.example.com to example.com, and so on, if + that is applicable). + + Although this document proposes a DDDS application that does not use + all the features of NAPTR resource records, it does not mean to imply + that DNS resolvers should fail to implement all aspects of the NAPTR + RR standard. A DDDS application is a client use convention. + + The rest of this section outlines the specific elements that protocol + developers must determine and document in order to make use of S- + NAPTR. + +3.1.1 Registration of application service and protocol tags + + Application protocol developers that wish to make use of S-NAPTR must + make provision to register any relevant application service and + application protocol tags, as described in Section 6. + + + +Daigle & Newton Expires August 15, 2004 [Page 6] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +3.1.2 Definition of conditions for retry/failure + + One other important aspect that must be defined is the expected + behaviour for interacting with the servers that are reached via S- + NAPTR. Specifically, under what circumstances should the client + retry a target that was found via S-NAPTR? What should it consider a + failure that causes it to return to the S-NAPTR process to determine + the next serviceable target (a less preferred target)? + + For example, if the client gets a "connection refused" from a server, + should it retry for some (protocol-dependent) period of time? Or, + should it try the next-preferred target in the S-NAPTR chain of + resolution? Should it only try the next-preferred target if it + receives a protocol-specific permanent error message? + + The most important thing is to select one expected behaviour and + document it as part of the use of S-NAPTR. + + As noted earlier, failure to provide appropriate credentials to + identify the server as being authoritative for the original taret + domain is always considered a failure condition. + +3.1.3 Server identification and handshake + + As noted in Section 7, use of the DNS for server location increases + the importance of using protocol-specific handshakes to determine and + confirm the identity of the server that is eventually reached. + + Therefore, application protocol developers using S-NAPTR should + identify the mechanics of the expected identification handshake when + the client connects to a server found through S-NAPTR. + +3.2 Guidelines for Domain Administrators + + Although S-NAPTR aims to provide a "straightforward" application of + DDDS and use of NAPTR records, it is still possible to create very + complex chains and dependencies with the NAPTR and SRV records. + + Therefore, domain administrators are called upon to use S-NAPTR with + as much restraint as possible, while still achieving their service + design goals. + + The complete set of NAPTR, SRV and A RRs that are "reachable" through + the S-NAPTR process for a particular application service can be + thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR + or SRV records; each SRV record points to several A record lookups. + Even though a particular client can "prune" the tree to use only + those records referring to application protocols supported by the + + + +Daigle & Newton Expires August 15, 2004 [Page 7] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + client, the tree could be quite deep, and retracing the tree to retry + other targets can become expensive if the tree has many branches. + + Therefore, + + o Fewer branches is better: for both NAPTR and SRV records, provide + different targets with varying preferences where appropriate + (e.g., to provide backup services, etc), but don't look for + reasons to provide more. + + o Shallower is better: avoid using NAPTR records to "rename" + services within a zone. Use NAPTR records to identify services + hosted elsewhere (i.e., where you cannot reasonably provide the + SRV records in your own zone). + + +3.3 Guidelines for Client Software Writers + + To properly understand DDDS/NAPTR, an implementor must read [6]. + However, the most important aspect to keep in mind is that, if one + target fails to work for the application, it is expected that the + application will continue through the S-NAPTR tree to try the (less + preferred) alternatives. + +4. Illustrations + +4.1 Use Cases + + The basic intended use cases for which S-NAPTR has been developed + are: + + o Service discovery within a domain. For example, this can be used + to find the "authoritative" server for some type of service within + a domain (see the specific example in Section 4.2). + + o Multiple protocols. This is increasingly common as new + application services are defined. This includes the case of + instant messaging (a service) which can be offered with multiple + protocols (see Section 4.3). + + o Remote hosting. Each of the above use cases applies within the + administration of a single domain. However, one domain operator + may elect to engage another organization to provide an application + service. See Section 4.4 for an example that cannot be served by + SRV records alone. + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 8] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +4.2 Service Discovery within a Domain + + There are occasions when it is useful to be able to determine the + "authoritative" server for a given application service within a + domain. This is "discovery", because there is no a priori knowledge + as to whether or where the service is offered; it is therefore + important to determine the location and characteristics of the + offered service. + + For example, there is growing discussion of having a generic + mechanism for locating the keys or certificates associated with + particular application (servers) operated in (or for) a particular + domain. Here's a hypothetical case for storing application key or + certificate data for a given domain. The premise is that some + credentials registry (CredReg) service has been defined to be a leaf + node service holding the keys/certs for the servers operated by (or + for) the domain. Furthermore, it is assumed that more than one + protocol is available to provide the service for a particular domain. + This DDDS-based approach is used to find the CredReg server that + holds the information. + + Thus, the set of NAPTR records for thinkingcat.example might look + like this: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example. + + Note that another domain, offering the same application service, + might offer it using a different set of application protocols: + + anotherdomain.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example. + + +4.3 Multiple Protocols + + As it stands, there are several different protocols proposed for + offering "instant message" services. Assuming that "IM" was + registered as an application service, this DDDS application could be + used to determine the available services for delivering to a target. + + Two particular features of instant messaging should be noted: + + 1. gatewaying is expected to bridge communications across protocols + + 2. instant messaging servers are likely to be operated out of a + + + +Daigle & Newton Expires August 15, 2004 [Page 9] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + different domain than the instant messaging address, and servers + of different protocols may be offered by independent + organizations + + For example, "thinkingcat.example" may support its own servers for + the "ProtA" instant messaging protocol, but rely on outsourcing from + "example.com" for "ProtC" and "ProtB" servers. + + Using this DDDS-based approach, thinkingcat.example can indicate a + preference ranking for the different types of servers for the instant + messaging service, and yet the out-sourcer can independently rank the + preference and ordering of servers. This independence is not + achievable through the use of SRV records alone. + + Thus, to find the IM services for thinkingcat.example, the NAPTR + records for thinkingcat.example are retrieved: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. + IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com. + + and then the administrators at example.com can manage the preference + rankings of the servers they use to support the ProtB service: + + _ProtB._tcp.example.com. + ;; Pref Weight Port Target + IN SRV 10 0 10001 bigiron.example.com + IN SRV 20 0 10001 backup.im.example.com + IN SRV 30 0 10001 nuclearfallout.australia-isp.example + + +4.4 Remote Hosting + + In the Instant Message hosting example in Section 4.3, the service + owner (thinkingcat.example) had to host pointers to the hosting + service's SRV records in the thinkingcat.example domain. + + A better way to approach this is to have one NAPTR RR in the + thinkingcat.example domain pointing to all the hosted services, and + the hosting domain has NAPTR records for each service to map them to + whatever local hosts it chooses (and may change from time to time). + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 10] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com. + + + and then the administrators at example.com can break out the + individual application protocols and manage the preference rankings + of the servers they use to support the ProtB service (as before): + + thinkingcat.example.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com. + IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. + + + + _ProtC._tcp.example.com. + ;; Pref Weight Port Target + IN SRV 10 0 10001 bigiron.example.com + IN SRV 20 0 10001 backup.im.example.com + IN SRV 30 0 10001 nuclearfallout.australia-isp.example + + +4.5 Sets of NAPTR RRs + + Note that the above sections assumed that there was one service + available (via S-NAPTR) per domain. Often, that will not be the + case. Assuming thinkingcat.example had the CredReg service set up as + described in Section 4.2 and the instant messaging service set up as + described in Section 4.4, then a client querying for the NAPTR RR set + from thinkingcat.com would get the following answer: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com. + IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example. + + Sorting them by increasing "ORDER", the client would look through the + SERVICE strings to determine if there was a NAPTR RR that matched the + application service it was looking for, with an application protocol + it could use. The first (lowest PREF) record that so matched is the + one the client would use to continue. + +4.6 Sample sequence diagram + + Consider the example in Section 4.3. Visually, the sequence of steps + + + +Daigle & Newton Expires August 15, 2004 [Page 11] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + required for the client to reach the final server for a "ProtB" + service for IM for the thinkingcat.example domain is as follows: + + + Client NS for NS for + thinkingcat.example example.com backup.im.example.com + | | | + 1 -------->| | | + 2 <--------| | | + 3 ------------------------------>| | + 4 <------------------------------| | + 5 ------------------------------>| | + 6 <------------------------------| | + 7 ------------------------------>| | + 8 <------------------------------| | + 9 ------------------------------------------------->| + 10 <-------------------------------------------------| + 11 ------------------------------------------------->| + 12 <-------------------------------------------------| + (...) + + + + 1. the name server (NS) for thinkingcat.example is reached with a + request for all NAPTR records + + 2. the server responds with the NAPTR records shown in Section 4.3. + + 3. the second NAPTR record matches the desired criteria; that has an + "s" flag and a replacement fields of "_ProtB._tcp.example.com". + So, the client looks up SRV records for that target, ultimately + making the request of the NS for example.com. + + 4. the response includes the SRV records listed in Section 4.3. + + 5. the client attempts to reach the server with the lowest PREF in + the SRV list -- looking up the A record for the SRV record's + target (bigiron.example.com). + + 6. the example.com NS responds with an error message -- no such + machine! + + 7. the client attempts to reach the second server in the SRV list, + and looks up the A record for backup.im.example.com + + 8. the client gets the A record with the IP address for + backup.im.example.com from example.com's NS. + + + + +Daigle & Newton Expires August 15, 2004 [Page 12] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + 9. the client connects to that IP address, on port 10001 (from the + SRV record), using ProtB over tcp. + + 10. the server responds with an "OK" message. + + 11. the client uses ProtB to challenge that this server has + credentials to operate the service for the original domain + (thinkingcat.example) + + 12. the server responds, and the rest is IM. + + +5. Motivation and Discussion + + Increasingly, application protocol standards are using domain names + to identify server targets, and stipulating that clients should look + up SRV resource records to determine the host and port providing the + server. This enables a distinction between naming an application + service target and actually hosting the server. It also increases + flexibility in hosting the target service: + + o the server may be operated by a completely different organization + without having to list the details of that organization's DNS + setup (SRVs) + + o multiple instances can be set up (e.g., for load balancing or + secondaries) + + o it can be moved from time to time without disrupting clients' + access, etc. + + This is quite useful, but Section 5.1 outlines some of the + limitations inherent in the approach. + + That is, while SRV records can be used to map from a specific service + name and protocol for a specific domain to a specific server, SRV + records are limited to one layer of indirection, and are focused on + server administration rather than on application naming. And, while + the DDDS specification and use of NAPTR allows multiple levels of + redirection before locating the target server machine with an SRV + record, this proposal requires only a subset of NAPTR strictly bound + to domain names, without making use of the REGEXP field of NAPTR. + These restrictions make the client's resolution process much more + predictable and efficient than with some potential uses of NAPTR + records. This is dubbed "S-NAPTR" -- a "S"traightforward use of + NAPTR records. + + + + + +Daigle & Newton Expires August 15, 2004 [Page 13] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +5.1 So, why not just SRV records? + + An expected question at this point is: this is so similar in + structure to SRV records, why are we doing this with DDDS/NAPTR? + + Limitations of SRV include: + + o SRV provides a single layer of indirection -- the outcome of an + SRV lookup is a new domain name for which the A RR is to be found. + + o the purpose of SRV is focused on individual server administration, + not application naming: as stated in [5] "The SRV RR allows + administrators to use several servers for a single domain, to move + services from host to host with little fuss, and to designate some + hosts as primary servers for a service and others as backups." + + o target servers by "service" (e.g., "ldap") and "protocol" (e.g., + "tcp") in a given domain. The definition of these terms implies + specific things (e.g., that protocol should be one of UDP or TCP) + without being precise. Restriction to UDP and TCP is insufficient + for the uses described here. + + The basic answer is that SRV records provide mappings from protocol + names to host and port. The use cases described herein require an + additional layer -- from some service label to servers that may in + fact be hosted within different administrative domains. We could + tweak SRV to say that the next lookup could be something other than + an address record, but that is more complex than is necessary for + most applications of SRV. + +5.2 So, why not just NAPTR records? + + That's a trick question. NAPTR records cannot appear in the wild -- + see [6]. They must be part of a DDDS application. + + The purpose here is to define a single, common mechanism (the DDDS + application) to use NAPTR when all that is desired is simple DNS- + based location of services. This should be easy for applications to + use -- some simple IANA registrations and it's done. + + Also, NAPTR has very powerful tools for expressing "rewrite" rules. + That power (==complexity) makes some protocol designers and service + administrators nervous. The concern is that it can translate into + unintelligible, noodle-like rule sets that are difficult to test and + administer. + + This proposed DDDS application specifically uses a subset of NAPTR's + abilities. Only "replacement" expressions are allowed, not "regular + + + +Daigle & Newton Expires August 15, 2004 [Page 14] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + expressions". + +6. IANA Considerations + + This document calls for 2 IANA registries: one for application + service tags, and one for application protocol tags. + + Application service and protocol tags should be defined in an RFC + (unless the "x-" experimental form is used, in which case they are + unregistered). There are no restrictions placed on the tags other + than that they must conform with the syntax defined below (Appendix + A.5). The IANA registries should list the tags and the RFC that + defines their use. + +7. Security Considerations + + The security of this approach to application service location is only + as good as the security of the DNS servers along the way. If any of + them is compromised, bogus NAPTR and SRV records could be inserted to + redirect clients to unintended destinations. This problem is hardly + unique to S-NAPTR (or NAPTR in general). + + To protect against DNS-vectored attacks, applications should define + some form of end-to-end authentication to ensure that the correct + destination has been reached. Many application protocols such as + HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims + to accomplish this task. + + The basic mechanism works in the following way: + + 1. During some portion of the protocol handshake, the client sends + to the server the original name of the desired destination (i.e. + no transformations that may have resulted from NAPTR + replacements, SRV targets, or CNAME changes). In certain cases + where the application protocol does not have such a feature but + TLS may be used, it is possible to use the "server_name" TLS + extension. + + 2. The server sends back to the client a credential with the + appropriate name. For X.509 certificates, the name would either + be in the subjectDN or subjectAltName fields. For Kerberos, the + name would be a service principle name. + + 3. Using the matching semantics defined by the application protocol, + the client compares the name in the credential with the name sent + to the server. + + 4. If the names match, there is reasonable assurance that the + + + +Daigle & Newton Expires August 15, 2004 [Page 15] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + correct end point has been reached. + + It is important to note that this document does not define either the + handshake mechanism, the specific credenential naming fields, nor the + name matching semantics. Definitions of S-NAPTR for particular + application protocols MUST define these. + +8. Acknowledgements + + Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for + discussion and input that has (hopefully!) provoked clarifying + revisions of this document. + +References + + [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + One: The Comprehensive DDDS", RFC 3401, October 2002. + + [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, October + 2002. + + [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Four: The Uniform Resource Identifiers (URI)", RFC 3404, October + 2002. + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 16] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Authors' Addresses + + Leslie Daigle + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + EMail: leslie@verisignlabs.com; leslie@thinkingcat.com + + + Andrew Newton + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + EMail: anewton@verisignlabs.com + +Appendix A. Application Service Location Application of DDDS + + This section defines the DDDS application, as described in [6]. + +A.1 Application Unique String + + The Application Unique String is domain label for which an + authoritative server for a particular service is sought. + +A.2 First Well Known Rule + + The "First Well Known Rule" is identity -- that is, the output of the + rule is the Application Unique String, the domain label for which the + authoritative server for a particular service is sought. + +A.3 Expected Output + + The expected output of this Application is the information necessary + to connect to authoritative server(s) (host, port, protocol) for an + application service within a given a given domain. + +A.4 Flags + + This DDDS Application uses only 2 of the Flags defined for the + URI/URN Resolution Application ([8]): "S" and "A". No other Flags + are valid. + + Both are for terminal lookups. This means that the Rule is the last + one and that the flag determines what the next stage should be. The + + + +Daigle & Newton Expires August 15, 2004 [Page 17] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + "S" flag means that the output of this Rule is a domain label for + which one or more SRV [5] records exist. "A" means that the output + of the Rule is a domain name and should be used to lookup address + records for that domain. + + Consistent with the DDDS algorithm, if the Flag string is empty the + next lookup is for another NAPTR record (for the replacement target). + +A.5 Service Parameters + + Service Parameters for this Application take the form of a string of + characters that follow this ABNF ([3]): + + service-parms = [ [app-service] *(":" app-protocol)] + app-service = experimental-service / iana-registered-service + app-protocol = experimental-protocol / iana-registered-protocol + experimental-service = "x-" 1*30ALPHANUMSYM + experimental-protocol = "x-" 1*30ALPHANUMSYM + iana-registered-service = ALPHA *31ALPHANUMSYM + iana-registered-protocol = ALPHA *31ALPHANUM + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + DIGIT = %x30-39 ; 0-9 + SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." + ALPHANUMSYM = ALPHA / DIGIT / SYM + ; The app-service and app-protocol tags are limited to 32 + ; characters and must start with an alphabetic character. + ; The service-parms are considered case-insensitive. + + Thus, the Service Parameters may consist of an empty string, just an + app-service, or an app-service with one or more app-protocol + specifications separated by the ":" symbol. + + Note that this is similar to, but not the same as the syntax used in + the URI DDDS application ([8]). The DDDS DNS database requires each + DDDS application to define the syntax of allowable service strings. + The syntax here is expanded to allow the characters that are valid in + any URI scheme name (see [1]). Since "+" (the separator used in the + RFC3404 service parameter string) is an allowed character for URI + scheme names, ":" is chosen as the separator here. + +A.5.1 Application Services + + The "app-service" must be a registered service [this will be an IANA + registry; this is not the IANA port registry, because we want to + define services for which there is no single protocol, and we don't + want to use up port space for nothing]. + + + + + +Daigle & Newton Expires August 15, 2004 [Page 18] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +A.5.2 Application Protocols + + The protocol identifiers that are valid for the "app-protocol" + production are any standard, registered protocols [IANA registry + again -- is this the list of well known/registered ports?]. + +A.6 Valid Rules + + Only substitution Rules are permitted for this application. That is, + no regular expressions are allowed. + +A.7 Valid Databases + + At present only one DDDS Database is specified for this Application. + [7] specifies a DDDS Database that uses the NAPTR DNS resource record + to contain the rewrite rules. The Keys for this database are encoded + as domain-names. + + The First Well Known Rule produces a domain name, and this is the Key + that is used for the first lookup -- the NAPTR records for that + domain are requested. + + DNS servers MAY interpret Flag values and use that information to + include appropriate NAPTR, SRV or A records in the Additional + Information portion of the DNS packet. Clients are encouraged to + check for additional information but are not required to do so. See + the Additional Information Processing section of [7] for more + information on NAPTR records and the Additional Information section + of a DNS response packet. + +Appendix B. Pseudo pseudocode for S-NAPTR + +B.1 Finding the first (best) target + + Assuming the client supports 1 protocol for a particular application + service, the following pseudocode outlines the expected process to + find the first (best) target for the client, using S-NAPTR. + + + target = [initial domain] + naptr-done = false + + while (not naptr-done) + { + NAPTR-RRset = [DNSlookup of NAPTR RRs for target] + [sort NAPTR-RRset by ORDER, and PREF within each ORDER] + rr-done = false + cur-rr = [first NAPTR RR] + + + +Daigle & Newton Expires August 15, 2004 [Page 19] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + while (not rr-done) + if ([SERVICE field of cur-rr contains desired application + service and application protocol]) + rr-done = true + target= [REPLACEMENT target of NAPTR RR] + else + cur-rr = [next rr in list] + + if (not empty [FLAG in cur-rr]) + naptr-done = true + } + + port = -1 + + if ([FLAG in cur-rr is "S"]) + { + SRV-RRset = [DNSlookup of SRV RRs for target] + [sort SRV-RRset based on PREF] + target = [target of first RR of SRV-RRset] + port = [port in first RR of SRV-RRset] + } + + ; now, whether it was an "S" or an "A" in the NAPTR, we + ; have the target for an A record lookup + + host = [DNSlookup of target] + + return (host, port) + + + +B.2 Finding subsequent targets + + The pseudocode in Appendix B is crafted to find the first, most + preferred, host-port pair for a particular application service an + protocol. If, for any reason, that host-port pair did not work + (connection refused, application-level error), the client is expected + to try the next host-port in the S-NAPTR tree. + + The pseudocode above does not permit retries -- once complete, it + sheds all context of where in the S-NAPTR tree it finished. + Therefore, client software writers could + + o entwine the application-specific protocol with the DNS lookup and + RRset processing described in the pseudocode and continue the S- + NAPTR processing if the application code fails to connect to a + located host-port pair; + + + + +Daigle & Newton Expires August 15, 2004 [Page 20] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + o use callbacks for the S-NAPTR processing; + + o use an S-NAPTR resolution routine that finds *all* valid servers + for the required application service and protocol from the + originating domain, and provides them in sorted order for the + application to try in order. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 21] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 22] + diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt new file mode 100644 index 0000000..4a01d91 --- /dev/null +++ b/doc/draft/draft-danisch-dns-rr-smtp-03.txt @@ -0,0 +1,1960 @@ + + + +INTERNET-DRAFT Hadmut Danisch +Category: Experimental Oct 2003 +Expires: Apr 1, 2004 + + The RMX DNS RR and method for lightweight SMTP sender authorization + draft-danisch-dns-rr-smtp-03.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + +Abstract + + This memo introduces a new authorization scheme for SMTP e-mail + transport. It is designed to be a simple and robust protection + against e-mail fraud, spam and worms. It is based solely on + organisational security mechanisms and does not require but still + allow use of cryptography. This memo also focuses on security and + privacy problems and requirements in context of spam defense. In + contrast to prior versions of the draft a new RR type is not + required anymore. + + + + + + + + + + + + +Hadmut Danisch Experimental [Page 1] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Table of Contents + + +1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 +2. Problem and threat description . . . . . . . . . . . . . . . . . 4 + 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4 + 2.1.1 Definition of sender forgery . . . . . . . . . . . 4 + 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5 + 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5 + 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6 + 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6 + 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7 +3. A DNS based sender address verification . . . . . . . . . . . . 7 + 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9 + 3.3. Domain part vs. full sender address . . . . . . . . . . . 9 +4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10 + 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10 + 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11 +5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11 + 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11 + 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12 + 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13 + 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14 + 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14 + 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15 + 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15 + 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16 +6. Optional and experimental entry types . . . . . . . . . . . . . 16 + 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16 + 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16 + 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17 + 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17 +7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17 + 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18 + 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18 + 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18 + 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18 + 7.2.5 Encoding of unused and full query . . . . . . . . . 19 + 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19 +8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19 + + + +Hadmut Danisch Experimental [Page 2] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20 +10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20 + 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20 + 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21 + 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21 +11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22 + 11.1. Draft specific considerations . . . . . . . . . . . . . . 22 + 11.1.1 Authentication strength . . . . . . . . . . . . . 22 + 11.1.2 Where Authentication and Authorization end . . . . 22 + 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23 + 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25 + 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25 + 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25 + 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26 + 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26 + 11.2. General Considerations about spam defense . . . . . . . . 27 + 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27 + 11.2.2 Content based Denial of Service attacks . . . . . 27 +12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Draft specific considerations . . . . . . . . . . . . . . 28 + 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28 + 12.1.2 Message reception and sender domain . . . . . . . 28 + 12.1.3 Network structure . . . . . . . . . . . . . . . . 29 + 12.1.4 Owner information distribution . . . . . . . . . . 29 + 12.2. General Considerations about spam defense . . . . . . . . 29 + 12.2.1 Content leaking of content filters . . . . . . . . 29 + 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30 +13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30 + 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30 + 13.1.1 Compatibility with old mail receivers . . . . . . 30 + 13.1.2 Compatibility with old mail senders . . . . . . . 30 + 13.1.3 Compatibility with old DNS clients . . . . . . . . 30 + 13.1.4 Compatibility with old DNS servers . . . . . . . . 30 + 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31 +14. General considerations about fighting spam . . . . . . . . . . 31 + 14.1. The economical problem . . . . . . . . . . . . . . . . . 31 + 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32 + 14.3. The network structure problem . . . . . . . . . . . . . . 33 + 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33 + 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33 + 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34 +Implementation and further Information . . . . . . . . . . . . . . . 34 +References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 +Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 +Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + + + + + + +Hadmut Danisch Experimental [Page 3] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +1. General Issues + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in + this document are to be interpreted as described in RFC 2119 [1]. + +2. Problem and threat description + +2.1. Mail sender forgery + + The amount of e-mails with forged sender addresses has dramatically + increased. As a consequence, damages and annoyances caused by such + e-mails increased as well. In the majority of examined e-mails the + domain name of the envelope sender address was forged, and the e- + mail was sent from an IP address which does not belong to a network + used by the actual owner of the domain. + +2.1.1. Definition of sender forgery + + As discussions, comments to prior versions of this draft, and + different approaches to stop forgery showed, different perceptions + of "mail forgery" exist. For example, there are mechanisms to + verify e-mail addresses for mailing lists, web servers, or to stop + spam, which do send a message with a random number to the given + address and expect the user to send a reply. Here, someone is + considered to be allowed to use a particular e-mail address, if and + only if he is able to receive informations sent to this address, + and is able to reply to such a message. While this definition + appears to be quite plausible and natural, it can't be used for a + simple technical solution. Sending back a challenge and expecting a + reply is simply too much overhead and time delay, and not every + authorized sender is able or willing to reply (e.g. because he went + offline or is not a human). + + Within the scope of this memo, sender forgery means that the + initiator of an e-mail transfer (which is the original sender in + contrast to relays) uses a sender address which he was not + authorized to use. Being authorized to use an address means that + the owner (administrator) of the internet domain has given + permission, i.e. agrees with the use of the address by that + particular sender. This memo will cover both the permission of the + full e-mail address and the domain part only for simplicity. + + Within context of Internet and SMTP, the sender address usually + occurs twice, once as the envelope sender address in SMTP, and once + as the address given in the RFC822 mail header. While the following + considerations apply to both addresses in principle, it is + important to stress that both addresses have distinct semantics and + + + +Hadmut Danisch Experimental [Page 4] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + are not neccessarily the same. The envelope address identifies the + initiator of the transport, while the header identifies the author + of the message content. Since this memo deals with the message + transport only and completely ignores the message content, the + method should naturally be applied to the envelope sender address. + +2.1.2. Spam + + A common and well known problem is the dramatic increase of + unsolicited e-mail, commonly called "spam". Again, the majority of + examined e-mails had forged sender addresses. The abused domains + were mainly those of common webmailers as hotmail or yahoo, or + well-known companies. + + Unfortunately, there is no accurate definition of spam availabe + yet, and neither are the concise technical criterions to filter or + block spam with technical mechanisms. There are efforts to design + content based filters, but these filters are expensive in + calculation time (and sometimes money), and they do not reliably + provide predictable results. Usually they give false positives + and/or require user interaction. Content filters in general suffer + from a design problem described later in this memo. Therefore, + this proposal does not use the content based approach to block + spam. + + As analysis of spam messages showed, most of spam messages were + sent with forged envelope sender addresses. This has mainly three + reasons. The first reason is, that spam senders usually do not + want to be contacted by e-mail. The second reason is, that they do + not want to be blacklisted easily. The third reason is, that spam + is or is going to be unlawful in many countries, and the sender + does not want to reveal his identity. Therefore, spam is considered + to be a special case of sender forgery. + +2.1.3. E-Mail Worms + + Another example of sender forgery is the reproduction of e-mail + worms. Most worms do choose random sender addresses, e.g. using + the addresses found in mailboxes on the infected system. In most + cases analyzed by the author, the e-mails sent by the reproduction + process can also be categorized as forged, since the infected + system would under normal circumstances not be authorized to send + e-mails with such e-mail addresses. So forgery does not require a + malicious human to be directly involved. This memo covers any kind + of e-mail sender address forgery, included those generated by + malicious software. + +2.1.4. E-Mail spoofing and fraud + + + +Hadmut Danisch Experimental [Page 5] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Forging e-mail sender addresses for fraud or other kinds of + deception ("human engineering") has also dramatically increased. + There are many known cases where single or mass e-mails were sent + with wrong sender addresses, pretending to come from service + provider, software manufacturers etc., and asking the receiver to + install any software or patches, or to reply with any confidential + information. The Internet is becoming more and more a scene of + crime, and so are it's services, including e-mail. It is obvious + that crime based on e-mail is eased by the fact that SMTP allows + arbitrary sender address spoofing. + +2.2. Indirect damage caused by forgery + + As observed by the author, mass mails and worms with forged sender + addresses can cause a severe damage for the real owner of the + abused sender addresses. If a sender A is sending an e-mail to the + receiver B, pretending to be C by using a sender address of C's + domain, then C has currently no chance to prevent this, since C's + machines and software are not involved in any way in the delivery + process between A and B. B will nevertheless send any error + messages (virus/spam alert, "no such user", etc.) to C, erroneously + assuming that the message was sent by C. The author found several + cases where this flood of error messages caused a severe denial of + service or a dramatic increase of costs, e.g. when C was + downloading the e-mail through expensive or low bandwidth + connections (e.g. modem or mobile phones), or where disk space was + limited. The author examined mass mailings, where several tens or + hundreds of thousands of messages were sent to several addresses + around the world, where these messages caused only annoyance. But + since several thousands of these addresses were invalid or didn't + accept the message, the owner of the DNS domain which was abused by + the spammer to forge sender addresses was flooded for several + months with thousands of error messages, jamming the e-mail system + and causing severe costs and damages. + + As a consequence, when A sends a message to B, pretending to be C, + there must be any mechanism to allow C to inform B about the fact, + that A is not authorized to use C as a sender address. This is what + this memo is about. + +2.3. Technical problem analysis + + Why does e-mail forgery actually exist? Because of the lack of the + Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender + authentication, authorisation, or verification. This protocol was + designed at a time where security was not an issue. Efforts have + been made to block forged e-mails by requiring the sender address + domain part to be resolvable. This method provides protection from + + + +Hadmut Danisch Experimental [Page 6] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + e-mails with non-existing sender domains, and indeed, for some time + it blocked most spam e-mails. However, since attackers and spam + senders began to abuse existing domain names, this method was + rendered ineffective. + +2.4. Shortcomings of cryptographical approaches + + At a first glance, the problem of sender address forgery might + appear to be solvable with cryptographic methods such as challenge + response authentications or digital signatures. A deeper analysis + shows that only a small, closed user group could be covered with + cryptographical methods. Any method used to stop spam forgery must + be suitable to detect forgery not only for a small number of + particular addresses, but for all addresses on the world. An + attacker does not need to know the secrets belonging to a + particular address. It is sufficient to be able to forge any + address and thus to know any secret key. Since there are several + hundreds of millions of users, there will always be a large amount + of compromised keys, thus spoiling any common cryptographic method. + Furthermore, cryptography has proven to be far too complicated and + error prone to be commonly administered and reliably implemented. + Many e-mail and DNS administrators do not have the knowledge + required to deal with cryptographic mechanisms. Many legislations + do not allow the general deployment of cryptography and a directory + service with public keys. For these reasons, cryptography is + applicable only to a small and closed group of users, but not to + all participants of the e-mail service. + +3. A DNS based sender address verification + +3.1. Overview + + To gain improvement in e-mail authenticity while keeping as much + SMTP compatibility as possible, a method is suggested which doesn't + change SMTP at all. + + The idea is to store informations about how to verify who is + authorized to transmit e-mails through SMTP with a particular + sender address (either full address or - for simplicity - only the + domain part of the address) in a directory service, which is + currently the DNS. To be precise, the verification consists of two + steps, the classical pair of authentication and authorization: + + The first step is the authentication. While several methods are + possible to perform authentication (see below), the most important + and robust method is the verification of the sender's IP address. + This is done implicitely by TCP/IP and the TCP sequence number. The + authenticated identity is the IP address. It has to be stressed + + + +Hadmut Danisch Experimental [Page 7] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + that this TCP/IP "authentication" is a weak authentication and + vulnerable to several attacks. It is nevertheless sufficient for + this purpose, especially for blocking spam. It doesn't take any + implementation and it doesn't cost: It is already there, it is a + functionality of TCP/IP. An incoming SMTP connection based on + TCP/IP already carries the sender's IP address without any + modification of SMTP. See below (section Entry types) for more + details about authentication methods. + + The second step is the authorization. It is based on the identity + given by the previous authentication step, e.g. the IP address of + the originator of the incoming SMTP connection, and on the + envelope sender address. The mechanism proposed in this memo + answers the question "Is that particular sender (IP address,...) + allowed to send with that sender address" by querying and + processing informations stored in a directory service, which is + DNS. + + When the sender has issued the "MAIL FROM:" SMTP command, the + receiving mail transfer agent (MTA) can - and modern MTAs do - + perform some authorization checks, e.g. run a local rule database + or check whether the sender domain is resolvable. + + The suggested method is to let the DNS server for the sender domain + provide informations about who - this means for example which IP + address - is authorized to use an address or a domain as a part of + it. After receiving the "MAIL FROM:" SMTP command, the receiving + MTA can verify, whether e. g. the IP address of the sending MTA is + authorized to send mails with this domain name. Therefore, a list + of entries with authorized IP addresses or other informations is + provided by the authoritative DNS server of that domain. The entry + types are described in the subsequent chapters. Some of these + methods are + + - An IPv4 or IPv6 network address and mask + - A fully qualified domain name referring to an A record + - A fully qualified domain name referring to an APL record + + RMX records of these types would look like this: + + somedomain.de. IN RMX ipv4:10.0.0.0/8 + rmxtest.de. IN RMX host:relay.provider.com + danisch.de. IN RMX apl:relays.rackland.de + relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24 + + where the machine with the example address 213.133.101.23 and the + machines in the example subnet 1.2.3.0/24 are the only machines + allowed to send e-mails with an envelope sender address of domain + + + +Hadmut Danisch Experimental [Page 8] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + danisch.de. Since the APL records do not necessarily belong to the + same domain or zone table as the RMX records, this easily allows to + refer to APL records defined by someone else, e.g. the internet + access or server hosting provider, thus reducing administrative + overhead to a minimum. In the example given above, the domain + danisch.de and several other domains are hosted by the service + provider Rackland. So if the relay structure of Rackland is + modified, only the zone of rackland.de needs to be modified. The + domain owners don't need to care about such details. + +3.2. Envelope vs. header sender address + + Questions were raised why the proposed mechanism is based on the + envelope sender address, and not on the sender address given in the + message header. Technically, both can be used. Actually, it makes + sense to use the envelope address. + + In common, the header sender address identifies the author of the + content, while the envelope sender tells who caused the + transmission. The approach proposed in this memo is transmission + based, not content based. We can not authorize the author of a + message if we don't have contact with him, if the message does not + already contain a signature. In contrast, the sending MTA is linked + to an IP address which can be used for authentication. This + mechanism might not be very strong, but it is available and + sufficient to solve today's e-mail security problems. + + Some people argued that it is the header address and not the sender + address, which is displayed in common mail readers (MUAs), and + where the receiver believes the mail comes from. That's true, but + it doesn't help. There are many cases where the header sender + differs from the envelope sender for good reasons (see below in the + consequences chapter for the discussion about relaying). Relaying, + mailing lists etc. require to replace the sender address used for + RMX. If this were the header address, the message header would have + to be modified. This is undesirable. + +3.3. Domain part vs. full sender address + + Former versions of this draft were limited to the domain part of + the sender address. The first reason is that it is common and MX- + like, to lookup only the domain part of an e-mail address in DNS. + The second reason is, that it was left to the private business of + the domain administration to handle details of user verification. + The idea was that the domain administration takes care to verify + the left part of an e-mail address with an arbitrary method of + their individual taste. RMX was originally designed to ignore the + left part of the address and to expect the domain administration to + + + +Hadmut Danisch Experimental [Page 9] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + take over responsibility for enforcing their policy. If, e.g., a + spam message arrived and passed the RMX mechanism, it is known to + be authorized by the domain administration and they can be blamed, + no matter what is on the left side of the sender address - it's + their private problem what happens on the left side of the @. By + far the most of the comments to prior versions of this draft agreed + with that. A few comments asked for a finer granularity. + + And indeed, there is no technical reason against a finer + granularity. All it takes is a mapping from a given envelope + sender address to a DNS name, and the RMX lookup for that + particular e-mail address could be done instead of a lookup for the + domain part only. However, to my knowledge, most domain + administrators would not like to provide an RMX entry for every + single e-mail address. In many cases, this would also overload DNS + servers. + + It is to be discussed how to cover both views. One method could be + to query the full address, and if no RMX records were found to + query the domain part only. A different approach would be to query + the domain part only, and if it's RMX record contain a special + entry, then a new query for the full address is triggered. A third + way would be to always query the full address and to leave the + problem to the wildcard mechanism of DNS. This still has to be + discussed and will be described in future versions of this draft. + + + + + + + + + + + +4. Mapping of E-Mail addresses to DNS names + + To perform the RMX query, a mapping is needed from E-Mail addresses + to DNS fully qualified domain names. + + This chapter is under development and just a first approach. + +4.1. Domain part only + + Mapping of the domain part is trivial, since the domain part of an + e-mail address itself is a valid DNS name and does not need + translation. It might be nevertheless desirable to distinguish the + + + +Hadmut Danisch Experimental [Page 10] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + RMX entries from other entries, depending of the encoding of the + records. If the RMX entries are encoded in TXT record types, they + might collide with other uses of TXT records. It might be + necessary to prepend the domain part with a special prefix, e.g. + _rmx. So the e-mail address some.user@example.com could be mapped + to example.com or _rmx.example.com. + +4.2. Full address + + Mapping a full address is slightly more difficult. The @ sign must + be unambiguously translated, and therefore can not be simply + translated into a dot. The e-mail addresses some.user@example.com + and some@user.example.com must have different mappings. Therefore, + the @ sign could be translated into _rmx, implicitely assuming that + this is not an allowed domain name component of normal domain + names. Then the rightmost _rmx in the mapped DNS name always + corresponds to the @ sign. some.user@example.com would e translated + into some.user._rmx.example.com and can be covered by a wildcard + entry like *._rmx.example.com. + + Character encoding and character sets are still to be discussed. + +4.3. Empty address + + Unfortunately, SMTP allows empty envelope sender addresses to be + used for error messages. Empty sender addresses can therefore not + be prohibited. As observed, a significant amount of spam was sent + with such an empty sender address. To solve this problem, the host + name given in the HELO or EHLO command is taken to lookup the RMX + records instead. This makes sense, since such messages were + generated by the machine, not a human. + + + + +5. Mandatory entry types and their syntax + + The entry types described in this section MUST be supported by any + implementation of this draft. + +5.1. Overall structure + + Similar to APL, an RMX record is just a concatenation of zero or + more RMX entries. The entries within one record form an ordered + rule base as commonly usual in packet filtes and firewall rulesets, + i. e. they are processed one ofter another until the first entry + matches. This entry determines the result of the query. Once a + matching entry is found, the RMX processing is finished. + + + +Hadmut Danisch Experimental [Page 11] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + For any domain name there should not exist more than a single RMX + record. Due to the structure of DNS, it is nevertheless possible to + have more than a single RMX record. Multiple RMX records are + treated as a single record consisting of the concatenation of all + records. While the entries in a record are ordered, the records are + not ordered and may be processed in arbitrary order. If the order + of the entries matters, it is the zone maintainer's responsibility + to keep those entries in a single record. For example, there are + negative entries, which exclude IP addresses from authorization. + It is important that these entries are processed before positive + entries giving permission to a wider address range. Since order is + guaranteed only within a record, corresponding negative and + positive entries must be put in the same record. + + An RMX record may consist of one or more entries, where the entries + are separated by whitespace. An entry must not contain white space. + Each entry consists of an optional exclamation sign, a tag, a + colon, and the entry data: + + [!] TAG : ENTRY-SPECIFIC-DATA + + If the entry starts with an exclamation sign, the entry is negated. + See the entry type description below for details. + + The TAG is the mnemonic type identifier or the decimal number of + the entry. The TAG is case-insensitive. It is immediately followed + by a colon. + + The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the + entry type. See description below. + + Example: + + danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5 + ipv4:1.2.3.0/24 + +5.2. Unused + + This is a primitive entry which just says that this sender address + will never be used as a sender address under any circumstances. + Example: + + testdomain.danisch.de IN RMX unused: + +5.3. IPv4 and IPv6 address ranges + + These entry types contain a bit sequence representing a CIDR + address part. If that bit sequence matches the given IP address, + + + +Hadmut Danisch Experimental [Page 12] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + authorization is granted or denied, depending on the negation flag. + + The entry is prepended with the tag "IPv4" or "IPv6". The colon is + followed with an IPv4 or IPv6 address in standard notation, + optionally followed by a slash and a mask length. If the negation + flag is set, then the given address range is excluded. Examples: + + danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0 + IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16 + IN RMX !ipv4:1.2.3.4 + + (Please note that it does not make much sense to use + RFC1918-Addresses in RMX records, this is just to give a syntax + example.) + + +5.4. DNS Hostname + + This entry type simply contains a regular DNS name, which is to be + resolved as a host name (fetch the A record or IPv6 equivalent). If + the given IP address matches the result, authorization is granted + or denied, depending on the negation flag. It is still to be + defined how to treat unresolvable entries. + + The entry is prepended with the tag "host", followed by a colon and + the hostname. Examples: + + danisch.de IN RMX host:relay.provider.de + IN RMX !host:badmachine.domain.de apl:relays.domain.de + +5.4.1. Road warriors and DynDNS entries + + Several people argued against RMX that it would break their + existing installation which delivers e-mail from dynamically + assigned IP addresses, because their IP providers didn't assign a + static address, or because they are a road warrior, plugging their + notebook in any hotel room on the world. + + RMX provides a simple solution. If such a machine has a dynamically + updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of + the hostname type pointing to this dynamic DNS entry. + + The cleaner solution would be to deliver mail the same way as it is + received: If downloaded by POP from a central relay with a static + address, where the MX points to, then it would be a good idea to + deliver e-mail the same way in reverse direction. Unfortunately, + plain POP does not support uploading yet. + + + + +Hadmut Danisch Experimental [Page 13] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +5.5. APL Reference + + This entry type simply contains a regular DNS name, which is to be + resolved as an APL record index (fetch the APL record). If the + given IP address positively matches the APL, authorization is + granted. Details of the semantic (espially when the negation bit is + set) are still to be defined. It is still to be defined how to + treat unresolvable entries. + + The entry is prepended with the tag "host", followed by a colon and + the hostname. Example: + + danisch.de IN RMX apl:relays.rackland.de + +5.6. Domain Member + + In many cases it is desirable to cover all hosts of a given domain + with an RMX record without the need to duplicate the list of these + hosts. This entry type does it (thanks to Eric A. Hall for pointing + out this entry type). It contains a regular DNS name. + + If this entry type is given, a reverse DNS query for the IP address + of the sending MTA is performed to find its official fully + qualified domain name. To prevent spoofing, this domain name is + accepted only if a subsequent address query to the given domain + name points to exactly the IP address of the sending MTA (the usual + procedure to verify PTR records). + + The entry matches if the fully qualified domain name of the sending + MTA ends in the given domain. The negation flag works as usual. + + The tag for this entry type is "domain". After the colon the domain + name is given, but might be empty, thus pointing to itself. + Example: + + somedomain.org IN RMX domain:somedomain.org domain:provider.com + + would authorize all machines which's hostname can be verified + through an PTR and A query, and which ends in "somedomain.org" or + "provider.com". + + With such an entry, large companies with different networks can + easily be covered with just a single and simple RMX entry. + Obviously, it requires proper PTR records. + + As a special shortcut, the DNS name may be empty. In this case the + domain name of the zone itself is taken. Thus, with a very simple + entry of the type + + + +Hadmut Danisch Experimental [Page 14] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + somecompany.com IN RMX domain: + + a company could authorize all machines which's IP addresses map to + DNS names end in somecompany.com, which applies in the majority of + companies. + + + + +5.7. Full Address Query + + As described above, RMX records will in most cases apply to the + domain part of the sender address. In special cases it might be + desirable to query the RMX record for a particular address. An RMX + entry of the Full Address Query type may occur in a domain RMX + record only. It signals that the RMX record for the full address is + to be fetched and processed. + + This entry type does not take arguments. The negation flag is not + supported. The tag is "full". + + If such a full address query is to be performed, the mail address + must be mapped to a valid and non-ambiguos DNS name. This mapping + is still to be defined. It is not sufficient to simply replace the + @ with a dot, because of case sensitivity, character sets, etc. The + e-mail addresses + + john.doe@example.org + John.Doe@example.org + john@doe.example.org + + must all be mapped to different DNS entries. This entry type might + vanish in future versions of the draft, depending on the discussion + about whether to query the domain name part only or the full + address. + +5.8. DNS mapped authorization + + As I learned from comments to prior versions of the draft and from + alternative proposals, many users wish to have a DNS mapped + authorization table, i. e. the client queries a DNS entry of the + form a.b.c.d.domain, where a.b.c.d is the sender's IP address. + Since people wish to have this, RMX will now include such a mapping + entry. The entry has a parameter giving the DNS domain name where + to look at. If the parameter is empty, then the same domain is + taken as for the RMX lookup. + + As this is currently under construction and discussion in an IETF + + + +Hadmut Danisch Experimental [Page 15] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + group, details will be published in future versions of this draft. + +5.9. RMX reference + + This entry type has no parameters. It means that all those machines + are authorized, which are pointed to by an MX record. + +6. Optional and experimental entry types + + The following subsections roughly describe further entry types + which might not be supported by all implementations and might not + be allowed in all legislations. These methods might vanish in + future versions of the draft and are just considerations about what + to include in RMX and what to not include. The main purpose of this + section is to start discussion about such entry types. + + The disadvantage of the following methods is that they violate the + basic idea of RMX, i. e. to be simple, robust, easy to implement + and easy to administer. I personally do not believe that it is a + good idea or even feasible to implement cryptography for a world + wide e-mail transfer network. Keep in mind that cryptographic keys + can be copied. If only <0.1% of cryptographic keys were revealed, + this completely compromises and spoils RMX. Cryptography is simply + the wrong tool for the problem RMX is intended to solve. I + nevertheless like to discuss these methods. + +6.1. TLS fingerprint + + The sender is considered to be authorized if the message was + transmitted through SMTP and TLS, and the sender used a certificate + matching the fingerprint given in the RMX record. + +6.2. TLS and LDAP + + This means that the receiver should perform an LDAP query for the + sender address (through the LDAP SRV record or given in the RMX + record), fetch the X.509 certificate for the sender. The sender is + considered to be authorized when the message was transmitted + through SMTP and TLS using this certificate. + +6.3. PGP or S/MIME signature + + It would be possible to accept a message only if it was signed with + PGP or S/MIME with a key which's fingerprint is given in the RMX + record or to be fetched from LDAP or any PGP database. This is + just for discussion, since it violates the idea of RMX to focus on + the transport, not on the content. It would also allow replay + attacks and not cover the envelope sender address or message + + + +Hadmut Danisch Experimental [Page 16] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + header. + +6.4. Transparent Challenge/Response + + It would also be possible to implement a challenge-response + mechanism without modifying the syntax of SMTP. For example, the + receiving MTA could issue a challenge with it's very first greeting + message, the sending MTA could hide the response in the HELO + parameter and when the receiving MTA later learns the sender + envelope address, it could verify the response based on + informations in the RMX record. + +6.5. SASL Challenge/Response + + Modern SMTP implementations already include a SASL mechanisms, + which easily allows to plugin new authentication mechanisms. While + common SASL mechanisms require to use a previously shared password, + a new mechanism could perform a challenge response authentication + as a SASL method. + + + + + + +7. Encoding + +7.1. Alternative encoding as TXT records + + The main objection against the prior versions of this draft was + that it requires a new RR entry type and upgrading all DNS servers. + + Therefore and alternative encoding is proposed. Instead of using a + new RR type, the TXT record type is used to contain the RMX record. + The records would simply look as described in the entry type + chapters above, e.g. + + _rmx.danisch.de. IN TXT "apl:relays.rackland.de" + + To allow smooth introduction of RMX without the need to immediately + upgrade all DNS servers, all clients (which have to be newly + installed anyway) MUST support both the TXT and the RMX records. A + client has to perform an ANY or a TXT and a RMX query. Servers/zone + tables may currently use TXT entries but SHOULD use RMX entries in + future. + +7.2. RMX Records + + + + +Hadmut Danisch Experimental [Page 17] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +7.2.1. Overall structure + + Each entry starts with an octet containting the entry type and the + negation flag: + + +---+---+---+---+---+---+---+---+------ + | N | Entry Type Code | Parameters... + +---+---+---+---+---+---+---+---+------ + + N If this bit (MSB) is set, an IP address + matching this entry is not authorized, + but explicitely rejected. See entry + type descriptions for details. + + Entry Type A 7bit number simply determining the entry + type. + + + Currently, entries do not have an explicit length field, the entry + length is determined implicitely by the entry type. Applications + are required to abort if an unknown entry type is found, instead of + skipping unknown entries. + +7.2.2. Record encoding + + A RMX record is simply a concatenation of RMX entries. + +7.2.3. Encoding of IPv4 and IPv6 address ranges + + After the entry type tag as described above, one octet follows + giving the length L of the bit sequence. Then a sequence of exactly + as many octets follows as needed to carry L bits of information (= + trunc((L+7)/8) ). + + +---+---+---+---+---+---+---+---+ + | N | Entry Type Code (1 or 2) | + +---+---+---+---+---+---+---+---+ + | Length Field L | + +---+---+---+---+---+---+---+---+ + | Bit Field | + / ((L+7)/8) Octets / + +---+---+---+---+---+---+---+---+ + + +7.2.4. Encoding of DNS + + After the entry type tag immediately follows a DNS encoded and + compressed [3] domain name. + + + +Hadmut Danisch Experimental [Page 18] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + +---+---+---+---+---+---+---+---+ + | N | Entry Type Code (3..5) | + +---+---+---+---+---+---+---+---+ + | Length Field L | + +---+---+---+---+---+---+---+---+ + | Encoded DNS | + / Name as described in RFC1035 / + +---+---+---+---+---+---+---+---+ + + In contrast to earlier versions of this draft, the DNS name cannot + be compressed, since this would cause decompression errors when a + DNS server is part of the query chain which does not know this + particular RR type. + +7.2.5. Encoding of unused and full query + + These entries do not contain parameters and does not allow the + negation flag. So the encoding is quite simple: + + +---+---+---+---+---+---+---+---+ + | 0 | Entry Type Code (6 or 7)| + +---+---+---+---+---+---+---+---+ + + + +7.2.6. Additional Records + + In order to avoid the need of a second query to resolve the given + host name, a DNS server should enclose the A record for that domain + name in the additional section of the additional section of the DNS + reply, if the server happens to be authoritative. + + In order to avoid the need of a second query to resolve the given + host name, a DNS server should enclose the APL record for that + domain name in the additional section of the additional section of + the DNS reply, if the server happens to be authoritative. + + + +8. Message Headers + + An RMX query must be followed by any kind of action depending on + the RMX result. One action might be to reject the message. Another + action might be to add a header line to the message body, thus + allowing MUAs and delivery programs to filter or sort messages. + + In future, the RMX result might be melted into the Received: header + line. + + + +Hadmut Danisch Experimental [Page 19] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + The details of such entries are to be discussed. As a proposal the + following form is suggested: + + X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM + + where + + RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX", + "TempFail", "BadData", "Trusted". + + ADDRESS is the IP address of the sending machine + + HOST is the name of the machine performing the RMX query. + + DATE is the date of the query. + + MECHANISM is the RMX method used to authorize the sender. + + + +9. SMTP error messages + + If a message is rejected because of RMX records, an error message + should be issued which explains the details. It is to be discussed + whether new SMTP error codes are to be defined. + + +10. Message relaying and forwarding + +10.1. Problem description + + Message forwarding and relaying means that an MTA which received an + e-mail by SMTP does not deliver it locally, but resends the message + - usually unchanged except for an additional Received header line + and maybe the recipient's address rewritten - to the next SMTP MTA. + Message forwarding is an essential functionality of e-mail + transport services, for example: + + - Message transport from outer MX relay to the intranet + - Message forwarding and Cc-ing by .forward or .procmail-alike + mechanisms + - Mailing list processing + - Message reception by mail relays with low MX priority, + usually provided by third parties as a stand-by service + in case of relay failure or maintenance + - "Forwarding" and "Bouncing" as a MUA functionality + + In all these cases a message is sent by SMTP from a host which is + + + +Hadmut Danisch Experimental [Page 20] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + not covered by the original sender domain's RMX records. While the + RMX records would forbid accepting this message, it still must be + accepted. The following subsections explain how to cope with + relaying. + +10.2. Trusted relaying/forwarding + + In some cases the receiving MTA trusts the sending MTA to not fake + messages and to already have checked the RMX records at message + reception. As a typical example, a company might have an outer mail + relay which receives messages from the Internet and checks the RMX + records. This relay then forwards the messages to the different + department's mail servers. It does not make sense for these + department mail servers to check the RMX record, since the RMX + records have already been checked and - since the message was + relayed by the outer relay - always would deny the message. In this + case there is a trust relationship between the department relays + and the outer relay. So RMX checking is turned off for trusted + relays. In this example, the department relays would not check + messages from the outer relay (but for intranet security, they + could still check RMX records of the other departments sub-domains + to avoid internal forgery between departments). + + Another common example are the low-priority MX relays, which + receive and cache e-mails when the high-priority relays are down. + In this case, the high-priority relay would trust the low-priority + relay to have verified the sender authorization and would not + perform another RMX verification (which would obviously fail). + + When a relay forwards a message to a trusting machine, the envelope + sender address should remain unchanged. + +10.3. Untrusted relaying/forwarding + + If the receiving MTA does not trust the forwarding MTA, then there + is no chance to leave the sender envelope address unchanged. At a + first glance this might appear impracticable, but this is + absolutely necessary. If an untrusted MTA could claim to have + forwarded a message from a foreign sender address, it could have + forged the message as well. Spammers and forgers would just have to + act as such a relay. + + Therefore, it is required that, when performing untrusted + forwarding, the envelope sender address has to be replaced by the + sender address of someone responsible for the relaying mechanism, + e.g. the owner of the mailing list or the mail address of the user + who's .forward caused the transmission. It is important to stress + that untrusted relaying/forwarding means taking over responsibility + + + +Hadmut Danisch Experimental [Page 21] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + for the message. It is the idea of RMX records to tie + responsibility to message transmission. Untrusted relaying without + replacing the sender address would mean to transmit without taking + responsibility. + + The disadvantage is that the original sender address is lost. + Therefore, whenever a sender address replacement happens, the + Received-Line must contain the old address. Many of today's MTAs + already insert the envelope recipient address, but not the sender + address into the Received header line. It seems reasonable to + require every Received line to include both the sender and + recipient address of the incoming SMTP connection. + + +11. Security Considerations + +11.1. Draft specific considerations + +11.1.1. Authentication strength + + It is important to stress, that the suggested method does not + provide high level security and does not completely prevent forged + e-mails or spam under any circumstances. It is a robust, but not + highly reliable and completely secure security mechanism. Keep in + mind that it is based on DNS, and DNS is not secure today. + Authorization is based on the IP address. The very same machine + with the very same IP address could be authorized to send e-mail + with a given sender address and sending spam at the same time. + Maybe because several users are logged in. Or because several + customers use the same relay of the same ISP, where one customer + could use the sender address of a different customer. It is up to + the ISP to prevent this or not. Machines can still be hijacked. + Spammers are also domain owners. They can simply use their own + domain and authorize themselves. You will always find people on the + world who do not care about security and open their relays and RMX + records for others to abuse them. RMX is to be considered as a + very cheap and simple light weight mechanism, which can + nevertheless provide a significant improvement in mail security + against a certain class of attacks, until a successor of SMTP has + been defined and commonly accepted. + +11.1.2. Where Authentication and Authorization end + + Previous versions of RMX records did not cover the local part of + the e-mail address, i.e. what's on the left side of the @ sign. + This is still to be discussed. Authentication and authorization are + limited to the sending MTA's IP address. The authentication is + limited to the TCP functionality, which is sufficient for light + + + +Hadmut Danisch Experimental [Page 22] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + weight authentication. The RMX records authorize the IP address of + the sending host only, not the particular sender of the message. So + if a machine is authorized to use sender addresses of more than a + single domain, the authentication scheme does not prevent that any + user on this machine can send with any of these domains. RMX is not + a substitute for the host security of the involved machines. + + The proposed authentication scheme can be seen as a "half way + authentication": It does not track back an e-mail to the effective + sender. It tracks only half of the way, i. e. it tracks back to the + domain and it's DNS administrators who authorized that particular + sender IP address to use it for sending e-mail. How the party + responsible for that domain performs user authentication, whom it + grants access to, how it helds people responsible for abuse, is + completely left as the private business of those who are in charge + of that domain. So this draft does not interfere with the domain's + individual security policy or any legislation about such policies. + On the other hand, the proposed authentication scheme does not give + any statement about the nature and quality of the domain's security + policy. This is an essential feature of the proposal: E-mail + authentication must be deployed world wide, otherwise it won't do + the job. Any security scheme interfering with the local + legislations or the domain's security policy will not be accepted + and can't effectively deployed. Therefore, the security policy must + remain the domain's private business, no matter how lousy the + policy might be. + + In order to achieve this and to make use of the only existing world + wide Internet directory scheme (DNS), the approach of this proposal + is to just ignore the local part of the sender address (i.e. what's + left of the @ part) and limit view to the domain part. After all, + that's what we do anyway when delivering to a given address with + SMTP. + +11.1.3. Vulnerability of DNS + + DNS is an essential part of the proposed authentication scheme, + since it requires any directory service, and DNS is currently the + only one available. Unfortunately, DNS is vulnerable and can be + spoofed and poisoned. This flaw is commonly known and weakens many + network services, but for reasons beyond that draft DNS has not + been significantly improved yet. After the first version of this + draft, I received several comments who asked me not to use DNS + because of its lack of security. I took this into consideration, + but came to the conclusion that this is unfeasible: Any + authentication scheme linked to some kind of symbolic identity (in + this case the domain name) needs some kind of infrastructure and + trusted assignment. There are basically two ways to do it: Do it + + + +Hadmut Danisch Experimental [Page 23] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + yourself and trust nobody else, or let someone else do it. There + are methods to do it the former way, e.g. to give someone some kind + of authentication information after a first successful e-mail + exchange, e.g. some kind of cookie or special e-mail address. This + is certainly interesting and powerful, but it does not solve the + problem on a world wide scale and is far to complicated and error + prone for the average user, i. e. 99% of the users. + + The latter method to let someone else do the symbolic name + assignment and create the authentication framework is well known. + It context of public key cryptography, this is called a Public Key + Infrastructure (PKI). On of the best known facts about PKIs is + that, until now, we don't have any covering a significant part of + the Internet. And we won't have any in near future. The complexity + is far too high, it is too expensive, and it involves cooperation + of every single user, which is simply unrealistic and extremely + error prone. So what do we have we can use? All we have is the DNS + and the Whois database. And we have countries who don't allow + cryptography. So the proposal was designed to use DNS without + cryptography. It does not avoid DNS because of its vulnerability, + it asks for a better DNS, but accepts the DNS as it is for the + moment. Currently there are two main threats caused by the DNS + weakness: + + - A spammer/forger could spoof DNS in order to gain false + authorization to send fake e-mails. + + - An attacker could spoof DNS in order to block delivery from + authorized machines, i. e. perform a Denial of Service attack. + + The first one is rather unrealistic, because it would require an + average spammer to poison a significant part of the DNS servers of + its victims. A spammer sending messages to one million receipients + would need to poison at least 1-10% which is 10,000 to 100,000 + receipient's DNS servers. This should be unfeasible in most cases. + + In contrast, the second threat is a severe one. If an attacker + wanted to block messages from one company to another, he just needs + to poison the recipients DNS server with a wrong RMX record in + order to make the recipient's SMTP machine reject all messages. And + this is feasible since the attacker needs to poison only a single + DNS server. But does this make SMTP more vulnerable? No. Because + the attacker can already do even more without RMX. By poisoning the + sender's DNS server with wrong MX records, the attacker can also + block message delivery or even redirect the messages to the + attacker's machine, thus preventing any delivery error messages and + furthermore getting access to the messages. + + + + +Hadmut Danisch Experimental [Page 24] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + As a consequence, e-mail delivery by SMTP requires a better DNS + anyway. The requirements are not significantly expanded by RMX. + +11.1.4. Sneaking RMX attack? + + While writing a test implementation, a certain kind of attack came + into my mind. I'm still not sure, whether this attack is possible + on any DNS server, but I believe it should be mentioned: + + Imagine an unauthorized sender is sending a forged mail (e.g. + spam). At connection time, before querying the RMX record, the + receiving MTA usually performs a PTR query for the IP address of + the sending MTA. If the sender has control over the authoritative + name server for that particular IP address, the sender could give a + normal PTR answer, but could append a wrong RMX, APL, or A record + in the additional section of the query. A subsequent RMX query + could receive wrong DNS data if the DNS server used by the + receiving MTA accepted those forged records. + +11.1.5. Open SMTP relays + + Open SMTP relays (i.e. machines who accept any e-mail message from + anyone and deliver to the world) abused by spammers are a one of + the main problems of spam defense and sender backtracking. In most + cases this problem just vanishes because foreign open relay + machines will not be covered by the RMX records of the forged + sender address. But there are two special cases: + + If the spammer knows about a domain which authorizes this + particular machine, that domain can be used for forgery. But in + this case, the IP address of the relay machine and the RMX records + of the domain track back to the persons responsible. Both can be + demanded to fix the relay or remove the RMX record for this + machine. An open relay is a security flaw like leaving the machine + open for everybody to login and send random mails from inside. Once + the administrative persons refuse to solve the problem, they can be + identified as spammers and held responsible. + + The second special case is when a domain authorizes all IP + addresses by having the network 0.0.0.0/0 in the RMX/APL record. In + this case, open relays don't make things worse. It's up to the + recipient's MTA to reject mails from domains with loose security + policies. + +11.1.6. Unforged Spam + + This proposal does not prevent spam (which is, by the way, not yet + exactly defined), it prevents forgery. Since spam is against law + + + +Hadmut Danisch Experimental [Page 25] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + and violates the recipients rights, spam depends on untracability + of the sender. In practice the sender forges the sender address + (other cases see below). This proposal is designed to detect such + forgeries. + + However, the RMX approach is rendered ineffective, if the sender + doesn't forge. If the sender uses just a normal address of it's own + domain, this is just a plain, normal e-mail, which needs to be let + through. Since it is up to the human's taste whether this is spam + or not, there's no technical way to reliably identify this as spam. + But since the sender domain is known, this domain can be + blacklisted or legal steps can be gone into. + +11.1.7. Reliability of Whois Entries + + Once the RMX infrastructure gets deployed, what's the security + gain? It allows to determine the domain which's DNS zone + authorized the sending machine. What's that good for? There are + some immediate uses of the domain name, e.g. in black- and + whitelisting. But in most cases this is just the starting point of + further investigations, either performed automatically before + message acceptance, or manually after spam has been received and + complainted about. + + The next step after determining the domain is determining the + people responsible for this domain. This can sometimes be achieved + by querying the Whois databases. Unfortunately, many whois entries + are useless because they are incomplete, wrong, obsolete, or in + uncommon languages. Furthermore, there are several formats of + address informations which make it difficult to automatically + extract the address. Sometimes the whois entry identifies the + provider and not the owner of the domain. Whois servers are not + built for high availability and sometimes unreachable. + + Therefore, a mandatory standard is required about the contents and + the format of whois entries, and the availability of the servers. + After receiving the MAIL FROM SMTP command with the sender envelope + address, the receiving MTA could check the RMX record and Whois + entry. If it doesn't point to a real human, the message could be + rejected and an error message like "Ask your provider to fix your + Whois entry" could be issued. Obviously, domain providers must be + held responsible for wrong entries. It might still be acceptable to + allow anonymous domains, i. e. domains which don't point to a + responsible human. But it is the receivers choice to accept e-mails + from such domains or not. + +11.1.8. Hazards for Freedom of Speech + + + + +Hadmut Danisch Experimental [Page 26] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Currently, some governments try to enforce limitations of internet + traffic in order to cut unwanted content providers from the + network. Some of these governments try to hide a whole country + behind firewalls, others try to force Internet providers to poison + DNS servers with wrong A records for web servers, e.g. one county + administration in Germany tries to do so. If message reception + depends on DNS entries, the same governments will try to block not + only HTTP, but SMTP also. + + However, since most MTAs already reject messages from unresolvable + domain names this is not a new threat. + +11.2. General Considerations about spam defense + + After discussing security requirements of the proposal, now the + security advantages of the RMX approach over content based filters + will be explained. Basically, there are three kinds of content + filters: + + - Those who upload the message or some digest to an external + third party and ask "Is this spam"? + + - Those who download a set of patterns and rules from a third + party and apply this set to incoming messages in order to + determine whether it is spam. + + - Those who are independent and don't contact any third party, + but try to learn themselves what is spam and what isn't. + + + The message filters provided by some e-mail service providers are + usually not a kind of their own, but a combination of the first two + kinds. + +11.2.1. Action vs. reaction + + Content filters suffer from a fundamental design problem: They are + late. They need to see some content of the same kind before in + order to learn and to block further distribution. + + This works for viruses and worms, which redistribute. This doesn't + work for spam, since spam is usually not redistributed after the + first delivery. When the filters have learned or downloaded new + pattern sets, it's too late. + + This proposal does not have this problem. + +11.2.2. Content based Denial of Service attacks + + + +Hadmut Danisch Experimental [Page 27] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + All three kinds of content filters, but especially the second and + the third kind are vulnerable to content based Denial of Service + attacks. + + If some kind of third party (e.g. non-democratic government, + intellectual property warriors, religious groups, military, secret + services, patriots, public relation agents, etc.) wants certain + contents not to be distributed, they could either poison the + pattern/rule databases or feed wrong sets to particular receivers. + + Such pattern/rule sets are the perfect tool for censoring e-mail + traffic and denial of service attacks by governments and other + parties, and a similar threat are virus filters. E. g. the content + industry could demand to teach all virus and spam filters to delete + all e-mails containing the URL of an MP3 web server outside the + legislations. Software manufacturers could try to block all e-mails + containing software license keys, thus trying to make unallowed + distribution more difficult. Governments could try to block + distribution of unwanted informations. + + This proposal does not have this problem. + + +12. Privacy Considerations + + (It was proposed on the 56th IETF meeting to have a privacy section + in drafts and RFCs.) + +12.1. Draft specific considerations + +12.1.1. No content leaking + + Since the RMX approach doesn't touch the contents of a message in + any way, there is obviously no way of leaking out any information + about the content of the message. RMX is based solely on the + envelope recipient address. However, methods to fix problems not + covered by RMX might allow content leaking, e.g. if the acceptance + of a message with an empty sender address requires the reference to + the message id of an e-mail recently sent, this allows an attacker + to verify whether a certain message was delivered from there. + +12.1.2. Message reception and sender domain + + Message delivery triggers RMX and APL requests by the recipient. + Thus, the admin of the DNS server or an eavesdropper could learn + that the given machine has just received a message with a sender + from this address, even if the SMTP traffic itself had been + encrypted. + + + +Hadmut Danisch Experimental [Page 28] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + However, most of today's MTAs do query the MX and A records of the + domain after the MAIL FROM command, so this is not a real new + threat. + +12.1.3. Network structure + + Since RMX and its associated APL records provide a complete list of + all IP addresses of hosts authorized to send messages from this + address, they do reveal informations about the network structure + and maybe the lifestyle of the domain owner, since a growing number + of domains are owned by single persons or families. E.g. the RMX + records could reveal where someone has his job or spends his time + at weekends. + + If such informations are to be kept secret, it is the user's job to + not sent e-mails from there and to relay them from non-compromising + IP addresses. + +12.1.4. Owner information distribution + + As described above, RMX depends partly on the reliability of the + whois database entries. It does not make anonymous domains + impossible, but it requires to keep the database entries "true", i. + e. if a whois entry does not contain informations about the + responsible person, this must be unambigously labeled as anonymous. + It must not contain fake names and addresses to pretend a non- + existing person. However, since most Internet users on the world + feel extremely annoyed by spam, they will urge their MTA admin to + reject messages from anonymous domains. The domain owner will have + the choice to either remain anonymous but be not able to send e- + mail to everyone in the world, or to be able but to reveal his + identity to everyone on the world. + + It would be possible to provide whois-like services only to + recipients of recent messages, but this would make things too + complicated to be commonly adopted. + +12.2. General Considerations about spam defense + +12.2.1. Content leaking of content filters + + As described above in the Security chapter, there are spam filters + which inherently allow leakage of the message body. Those filters + upload either the message body, or in most cases just some kind of + checksum to a third party, which replies whether this is to be seen + as spam or not. The idea is to keep a databases of all digests of + all messages. If a message is sent more often than some threshold, + it is to be considered as a mass mail and therefore tagged as spam. + + + +Hadmut Danisch Experimental [Page 29] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + While the digest itself does not reveal the content of the message, + it perfectly reveals where a particular message has been delivered + to. If a government finds just a single unwanted message, if a + software manufacturer finds a single message with a stolen product + license key, if someone finds a message with unpatriotic content, + it takes just a single database lookup to get a list of all people + who received this particular message. Content filters with digest + upload are the perfect "Big Brother". + +12.2.2. Black- and Whitelists + + Some proposals against spam are based on a central database of + white- or blacklisted IP addresses, Sender names, Message IDs or + whatever. Again, there is a central database which learns who has + received which e-mail or from which sender with every query. This + allows tracking relations between persons, which is also a breach + of privacy. + + + +13. Deployment Considerations + +13.1. Compatibility + +13.1.1. Compatibility with old mail receivers + + Since the suggested extension doesn't change the SMTP protocol at + all, it is fully compatible with old mail receivers. They simply + don't ask for the RMX records and don't perform the check. + +13.1.2. Compatibility with old mail senders + + Since the SMTP protocol is unchanged and the SMTP sender is not + involved in the check, the method is fully compatible with old mail + senders. + +13.1.3. Compatibility with old DNS clients + + Since the RMX is a new RR, the existing DNS protocol and zone + informations remain completely untouched. + + If RMX is provided as a TXT record instead, it must be ensured that + no other software is misinterpreting this entry. + +13.1.4. Compatibility with old DNS servers + + Full compatibility: If the server does not support RMX records, RMX + in TXT records can be used. + + + +Hadmut Danisch Experimental [Page 30] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +13.2. Enforcement policy + + Obviously, for reasons of backward compatibility and smooth + introduction of this scheme, RMX records can't be required + immediately. Domains without RMX records must temporarily be + treated the same way as they are treated right now, i.e. e-mail + must be accepted from anywhere. But once the scheme becomes + sufficiently widespread, mail relays can start to refuse e-mails + with sender addresses from domains without RMX records, thus + forcing the owner of the domain to include a statement of + authorization into the domain's zone table. Domain owners will + still be free to have an RMX record with a network and mask + 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere. + On the other hand, mail receivers will be free to refuse mails from + domains without RMX records or RMX records which are too loose. + Advanced MTAs might have a configuration option to set the maximum + number of IP addresses authorized to use a domain. E-mails from a + domain, which's RMX records exceed this limit, would be rejected. + For example, a relay could reject e-mails from domains which + authorize more than 8 IP addresses. That allows to accept e-mails + only from domains with a reasonable security policy. + + + +14. General considerations about fighting spam + + Is there a concise technical solution against spam? Yes. + + Will it be deployed? Certainly not. + + Why not? Because of the strong non-technical interests of several + parties against a solution to the problem, as described below. + Since these are non-technical reasons, they might be beyond the + scope of such a draft. But since they are the main problems that + prevent fighting spam, it is unavoidable to address them. This + chapter exists temporarily only and should support the discussion + of solutions. It is not supposed to be included in a later RFC. + +14.1. The economical problem + + As has been recently illustrated in the initial session of the + IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting, + sending spam is a business with significant revenues. + + But a much bigger business is selling Anti-Spam software. This is a + billion dollar market, and it is rapidly growing. Any simple and + effective solution against spam would defeat revenues and drive + several companies into bankrupt, would make consultants jobless. + + + +Hadmut Danisch Experimental [Page 31] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + Therefore, spam is essential for the Anti-Spam business. If there + is no spam, then no Anti-Spam software can be sold, similar to the + Anti-Virus business. There are extremely strong efforts to keep + this market growing. Viruses, Worms, and now spam are just perfect + to keep this market alive: It is not sufficient to just buy a + software. Databases need to be updated continuously, thus making + the cash flow continuously. Have a single, simple, and permanent + solution to the problem and - boom - this billion dollar market is + dead. + + That's one of the reasons why people are expected to live with + spam. They have to live with it to make them buy Anti-Spam + software. Content filters are perfect products to keep this market + alive. + +14.2. The POP problem + + Another problem is the history of mail delivery. Once upon a time, + there used to be very few SMTP relays which handled the e-mail + traffic of all the world, and everybody was happy with that. Then + odd things like Personal Computers, which are sometimes switched + off, portable computers, dynamicly assigned IP addresses, IP access + from hotel rooms, etc. was invented, and people became unhappy, + because SMTP does not support delivery to such machines. To make + them happy again, the Post Office Protocol[4] was invented, which + turned the last part of message delivery from SMTP's push style + into a pull style, thus making virtually every computer on the + world with any random IP address a potential receiver of mails for + random domains. Unfortunately, only receiving e-mail was covered, + but sending e-mail was left to SMTP. + + The result is that today we have only very few SMTP relays pointed + to by MX records, but an extreme number of hosts sending e-mail + with SMTP from any IP address with sender addresses from any + domain. Mail delivery has become very asymmetric. Insecurity, + especially forgeability, has become an essential part of mail + transport. + + That problem could easily be fixed: Use protocols which allow + uploading of messages to be delivered. If a host doesn't receive + messages by SMTP, it shouldn't deliver by SMTP. Mail delivery + should go the same way back that incoming mail went in. This is + not a limitation to those people on the road who plug their + portable computer in any hotel room's phone plug and use any + provider. If there is a POP server granting download access from + anywhere, then the same server should be ready to accept uploading + of outgoing messages. + + + + +Hadmut Danisch Experimental [Page 32] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + But as I saw from the comments on the first version of this draft, + people religiously insist on sending e-mail with their domain from + any computer with any IP address in the world, e.g. when visiting a + friend using her computer. It appears to be impossible to convince + people that stopping mail forgery requires every one of them to + give up forging. + +14.3. The network structure problem + + A subsequent problem is that many organisations failed to implement + a proper mail delivery structure and heavily based their network on + this asymmetry. I received harsh comments from Universities who + were unable to give their network a good structure. While they do + have a central mail relay for incoming mail to the universities + domain, they developed a structure where every member of the + University randomly sends e-mails with that University's domain as + a sender address from home or everywhere in the world with any + dynamically assigned IP address from any provider. So this domain + is to be used from every possible IP address on earth, and they are + unable to operate any authentication scheme. Furthermore, they were + unable to understand that such a policy heavily supports spam and + that they have to expect that people don't accept such e-mails + anymore once they become blacklisted. + + As long as organisations insist on having such policies, spammers + will have a perfect playground. + +14.4. The mentality problem + + Another problem is the mentality of many internet users of certain + countries. I received harsh comments from people who strongly + insisted on the freedom to send any e-mail with any sender address + from anywhere, and who heavily refused any kind of authentication + step or any limitation, because they claimed that this would + infringe their constitutional "Freedom of speech". They are + undeviatingly convinced that "Freedom of speech" guarantees their + right to talk to everybody with any sender address, and that is has + to be kept the recipient's own problem to sort out what he doesn't + want to read - on the recipient's expense. + + It requires a clear statement that the constitutional "Freedom of + Speech" does not cover molesting people with unsolicited e-mail + with forged sender address. + +14.5. The identity problem + + How does one fight against mail forgery? With authentication. What + is authentication? In simple words: Making sure that the sender's + + + +Hadmut Danisch Experimental [Page 33] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + + real identity meets the recipients idea of who is the sender, based + on the sender address which came with the message. + + What is identity? It is the main problem. Several countries have + different ideas of "identity", which turn out to be somehow + incompatible. In some countries people have identity cards and + never change their name and birthday. Identities are created by + human birth, not by identity changes. Other countries do not have + such a tight idea about identity. People's temporary identity is + based on nothing more than a driving license and a social security + number. With this background, it is virtually impossible to create + a trustworthy PKI covering all Internet users. I learned that it is + extremely difficult to convince some people to give up random e- + mail sending. + +14.6. The multi-legislation problem + + Many proposals about fighting spam are feasible under certain + legislations only, and are inacceptable under some of the + legislations. But a world wide applicable method is required. + That's why the approach to ask everone on the world to sign + messages with cryptographic keys is not feasible. + + +Implementation and further Information + + Further informations and a test implementation are available at + + http://www.danisch.de/work/security/antispam.html + http://www.danisch.de/software/rmx/ + + + Additional informations and a technology overview are also + available at + + http://www.mikerubel.org/computers/rmx_records/ + + +References + + + +1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- + els," RFC 2119 (March 1997). + +2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001). + + + + + +Hadmut Danisch Experimental [Page 34] + +INTERNET-DRAFT DNS RMX RR Oct 2003 + + +3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," + RFC 1035 (November 1987). + +4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939 + (May 1996). + + +Draft History + + 00 Dec 2002 + 01 Apr 2003 + 02 Jun 2003 + 03 Oct 2003 + +Author's Address + + Hadmut Danisch + + Tennesseeallee 58 + 76149 Karlsruhe + Germany + + Phone: ++49-721-843004 or ++49-351-4850477 + E-Mail: rfc@danisch.de + +Comments + + Please send comments to rfc@danisch.de. + +Expiry + + This drafts expires on Apr 1, 2004. + + + + + + + + + + + + + + + + + + + +Hadmut Danisch Experimental [Page 35] + diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt new file mode 100644 index 0000000..7b5e8cc --- /dev/null +++ b/doc/draft/draft-dnsext-opcode-discover-02.txt @@ -0,0 +1,241 @@ + +IETF DNSEXT WG Bill Manning +draft-dnsext-opcode-discover-02.txt ep.net + Paul Vixie + ISC + 13 Oct 2003 + + + The DISCOVER opcode + +This document is an Internet-Draft and is subject to all provisions of +Section 10 of RFC2026. + +Comments may be submitted to the group mailing list at "mdns@zocalo.net" +or the authors. + +Distribution of this memo is unlimited. + +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. + +The capitalized keywords "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 + +0. Abstract: + + The QUERY opcode in the DNS is designed for unicast. With the + development of multicast capabilities in the DNS, it is desireable + to have a more robust opcode for server interactions since a single + request may generate replies from multiple responders. So DISCOVER + is defined to deal with replies from multiple responders. + + As such, this document extends the core DNS specifications to allow + clients to have a method for coping with replies from multiple + responders. Use of this new opcode may facilitate DNS operations in + modern networking topologies. A prototype of the DISCOVER opcode + was developed during the TBDS project (1999-2000), funded under DARPA + grant F30602-99-1-0523. + +1. Introduction: + + This document describes an experimental extension to the DNS to receive + multiple responses which is the likely result when using DNS that has + enabled multicast queries. This approach was developed as part of the + TBDS research project, funded under DARPA grant F30602-99-1-0523. The + full processing rules used by TBDS are documented here for possible + incorporation in a future revision of the DNS specification." + +2. Method: + + DISCOVER works like QUERY except: + + 1. it can be sent to a broadcast or multicast destination. QUERY + isn't defined for non-unicast, and arguably shouldn't be. + + 2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA> + tuples. TBDS tried to augment this structure as follows: + <QNAME=service,QTYPE=SRV>. While this worked for our purposes in + TBDS, it is cleaner to place the SRV question in a separate pass. + + 3. if QDCOUNT equals 0 then only servers willing to do recursion should + answer. Other servers must silently discard the DISCOVER request. + + 4. if QDCOUNT is not equal to 0 then only servers who are authoritative + for the zones named by some QNAME should answer. + + 5. responses may echo the request's Question section or leave it blank, + just like QUERY. + + 6. responses have standard Answer, Authority, and Additional sections. + e.g. the response is the same as that to a QUERY. It is desireable + that zero content answers not be sent to avoid badly formed or + unfulfilled requests. Responses should be sent to the unicast + address of the requester and the source address should reflect + the unicast address of the responder. + + Example usage for gethostby{name,addr}-style requestors: + + Compute the zone name of the enclosing in-addr.arpa, ip6.int, or + ip6.arpa domain. + + DISCOVER whether anyone in-scope is authoritative for this zone. + + If so, query these authoritative servers for local + in-addr/ip6 names. + + If not, DISCOVER whether there are recursive servers available. + + If so, query these recursive servers for local + in-addr/ip6 names. + + So, a node will issue a multicast request with the DISCOVER opcode at + some particular multicast scope. Then determine, from the replies, + whether there are any DNS servers which are authoritative (or support + recursion) for the zone. Replies to DISCOVER requests MUST set the + Recursion Available (RA) flag in the DNS message header. + + It is important to recognize that a requester must be prepared to + receive multiple replies from multiple responders. We expect that + there will be a single response per responder. + + Once one learns a host's FQDN by the above means, repeat the process + for discovering the closest enclosing authoritative server of such + local name. + + Cache all NS and A data learned in this process, respecting TTL's. + + TBDS usage for SRV requestors: + + Do the gethostbyaddr() and gethostbyname() on one's own link-local + address, using the above process. + + Assume that the closest enclosing zone for which an authority server + answers an in-scope DISCOVER packet is "this host's parent domain". + + Compute the SRV name as _service._transport.*.parentdomain. + + This is a change to the definition as defined in RFC 1034. + A wildcard label ("*") in the QNAME used in a DNS message with + opcode DISCOVER SHOULD be evaluated with special rules. The + wildcard matches any label for which the DNS server data is + authoritative. For example 'x.*.example.com.' would match + 'x.y.example.com.' and 'x.yy.example.com.' provided that the + server was authoritative for 'example.com.' In this particular + case, we suggest the follwing considerations be made: + + getservbyname() can be satisfied by issuing a request with + this computed SRV name. This structure can be + populated by values returned from a request as follows: + + s_name The name of the service, "_service" without the + preceding underscore. + s_aliases The names returned in the SRV RRs in replies + to the query. + s_port The port number in the SRV RRs replies to the + query. If these port numbers disagree - one + of the port numbers is chosen, and only those + names which correspond are returned. + s_proto The transport protocol from named by the + "_transport" label, without the preceding + underscore. + + Send SRV query for this name to discovered local authoritative servers. + + Usage for disconnected networks with no authoritative servers: + + Hosts should run a "stub server" which acts as though its FQDN is a + zone name. Computed SOA gives the host's FQDN as MNAME, "." as the + ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE + and the other timers. Compute NS as the host's FQDN. Compute the + glue as the host's link-local address. Or Hosts may run a + "DNS stub server" which acts as though its FQDN is a zone name. The + rules governing the behavior of this stub server are given elsewhere + [1] [2]. + + Such stub servers should answer DISCOVER packets for its zone, and + will be found by the iterative "discover closest enclosing authority + server" by DISCOVER clients, either in the gethostbyname() or SRV + cases described above. Note that stub servers only answer with + zone names which exactly match QNAME's, not with zone names which + are owned by QNAME's. + + The main deviation from the DNS[3][4] model is that a host (like, say, a + printer offering LPD services) has a DNS server which answers authoritatively + for something which hasn't been delegated to it. However, the only way that + such DNS servers can be discovered is with a new opcode, DISCOVER, which + is explicitly defined to discover undelegated zones for tightly scoped + purposes. Therefore this isn't officially a violation of DNS's coherency + principles. In some cases a responder to DISCOVER may not be traditional + DNS software, it could be special purpose software. + +3. IANA Considerations + + As a new opcode, the IANA will need to assign a numeric value + for the memnonic. The last OPCODE assigned was "5", for UPDATE. + Test implementations have used OPCODE "6". + +4. Security Considerations + + No new security considerations are known to be introduced with any new + opcode, however using multicast for service discovery has the potential + for denial of service, primarly from flooding attacks. It may also be + possible to enable deliberate misconfiguration of clients simply by + running a malicious DNS resolver that claims to be authoritative for + things that it is not. One possible way to mitigate this effect is by + use of credentials, such as CERT resource records within an RR set. + The TBDS project took this approach. + +5. Attribution: + + This material was generated in discussions on the mdns mailing list +hosted by Zocalo in March 2000. Updated by discussion in September/October +2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock, +Erik Guttman, Bill Manning and Paul Vixie were active contributors. + +6. Author's Address + + Bill Manning + PO 12317 + Marina del Rey, CA. 90295 + +1.310.322.8102 + bmanning@karoshi.com + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + <vixie@isc.org> + +7. References + +Informational References: + +[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS", + draft-ietf-dnsext-mdns-00.txt, November 2000. Expired + +[2] Woodcock, B., Manning, B., "Multicast Domain Name Service", + draft-manning-dnsext-mdns-00.txt, August 2000. Expired. + +Normative References: +[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + RFC 1034, November 1987. +[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", + RFC 1035, November 1987 + + ----------------------------EOL----------------------- + diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt new file mode 100644 index 0000000..224e7ad --- /dev/null +++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt @@ -0,0 +1,240 @@ +Internet Engineering Task Force Alain Durand +INTERNET-DRAFT SUN Microsystems +Feb 21, 2003 +Expires Aug 2, 2003 + + + + Dynamic reverse DNS for IPv6 + <draft-durand-dnsop-dynreverse-00.txt> + + + +Status of this memo + + + This memo provides information to the Internet community. It does + not specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 [RFC2026]. + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + This document describes a method to dynamically generate PTR records + and corresponding A or AAAA records when the reverse path DNS tree is + not populated. + + A special domain dynrev.arpa. is reserved for that purpose. + + +1. Introduction + + In IPv4, the reverse path tree of the DNS under in-addr.arpa. + although not perfectly maintained, is still mostly usable and its + existence is important for a number of applications that relies on + its existence and decent status. Some applications performs some + (very) weak security checks based on it. Mail relays relies on it for + some anti-spams checks an some FTP server will not let you in unless + your IP address resolve properly with a PTR record. + + IPv6 addresses being much longer (and cumbersome) than IPv4 + addresses, it is to fear that the reverse path tree under ip6.arpa. + would not be as well maintained. Also, tools like 6to4, Isatap and + others have made creative use of the 128 bits of an IPv6 address to + automatically embed an IPv4 address to enable seamless connection to + the IPv6 Internet. However, no provision has been made to make sure + the reverse path tree gets automatically updated as well for those + new IPv6 addresses. One step furter, RFC3041 describes a mechanism + to basically use random bits in the bottom part of an IPv6 address to + preserver anonymity. If those addresses are to resolve in the reverse + path tree, it obviously has to be with anonymous data as well. + Another point to note is that home customer ISPs in IPv4 have a + current practice to pre-populate the reverse path tree with names + automatically derived from the IP addresses. This practice is no + longer possible in IPv6, where IP address allocation is not dense as + it is the case in IPv4. The mere size of typical customer allocation + (2^48 according to the recommendation of RFC3177) makes it + impossible. + + Applications that check the existence of PTR records usually follow + this by checking if the name pointed by the PTR resolve in a A (or + AAAA for IPv6) that match the original IP address. Thus the forward + path tree must also include the corresponding data. + + One simple approach of this problem is to simply declare the usage of + the reverse path DNS as described above obsolete. The author believe + this is too strong an approach for now. + + Similarly, a completely different approach would be to deprecate the + usage of DNS for the reverse tree altogether and replace it by + something inspired from ICMP name-info messages. The author believes + that this approached is an important departure from the current + practise and thus not very realistic. Also, there are some concerns + about the the security implications of this method as any node could + easily impersonate any name. This approach would fundamentally change + the underlying assumption of "I trust what has been put in the DNS by + the local administrators" to "I trust what has been configured on + each machine I query directly". + + + +2. Dynamic record generation + + If static pre-population of the tree is not possible anymore and data + still need to be returned to applications using getnameinfo(), the + alternative is dynamic record generation. This can be done is two + places: in the DNS servers responsible for the allocated space (/64 + or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the + sub resolver library or the recursive DNS server). + + 2.1. On the resolver side. + + The resolver, either in the recursive DNS server or in the stub + library could theoretically generate this data. + + In case DNSsec is in place, the recursive DNS server would have to + pretend these records are authentic. + + If the synthesis is done in the stub-resolver library, no record + needs to be actually generated, only the right information needs to + be passed to getnameinfo() and getaddrinfo(). If the synthesis is + done in the recursive DNS server, no modification is required to + existing stub resolvers. + + +2.2. On the server side. + + PTR records could be generated automatically by the server + responsible for the reverse path tree of an IPv6 prefix (a /64 or /48 + prefixes or basically anything in between) when static data is not + available. + + There could be impact on DNSsec as the zone or some parts of the zone + may need to be resigned each time a DNS query is made for an + unpopulated address. This can be seen as a DOS attack on a DNSsec + zone, so server side synthesis is not recommended if DNSsec is + deployed. + + + +3. Synthesis + + The algorithm is simple: Do the normal queries. If the query returns + No such domain, replace this answer by the synthetized one if + possible. + +3.1. PTR synthesis + + The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa. + where [X] is any valid DNS name. + + The fact that the synthetized PTR points to the dynrev.arpa. domain + is an indication to the applications that this record has been + dynamically generated. + + +3.2. A synthesis + + If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A + record for the string [X].dynrev.arpa. which value is d.c.b.a. with + a,b,c & d being integer [0..255] + + +3.3. AAAA synthesis + + If [X] is in the form + a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in- + addr.arpa, one can synthetized a AAAA record for the string + [X].dynrev.arpa. which value is + FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with + a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits. + + +3.4. Server side synthesis + + If synthesis is done on the server side, PTR could be set not to use + the dynrev.arpa domain but the local domain name instead. It culd be + for instance dynrev.mydomain.com. + + Note also that server side synthesis is not incompatible with + resolver side synthesis. + + + +4. IANA considerations + + The dynrev.arpa. domain is reserved for the purpose of this document. + + + +5. Security considerations + + Section 2. discusses the the interactions with DNSsec. + + + +6. Authors addresses + + Alain Durand + SUN Microsystems, Inc + 17, Network Circle + UMPK17-202 + Menlo Park, CA 94025 + USA + Mail: Alain.Durand@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt new file mode 100644 index 0000000..fa41e76 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories +Expires: February 2006 August 2005 + + + + Domain Name System (DNS) IANA Considerations + ------ ---- ------ ----- ---- -------------- + <draft-ietf-dnsext-2929bis-01.txt> + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this draft is unlimited. It is intended to become + the new BCP 42 obsoleting RFC 2929. Comments should be sent to the + DNS Working Group mailing list <namedroppers@ops.ietf.org>. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + Internet Assigned Number Authority (IANA) parameter assignment + considerations are given for the allocation of Domain Name System + (DNS) classes, RR types, operation codes, error codes, RR header + bits, and AFSDB subtypes. + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DNS Query/Response Headers..............................3 + 2.1 One Spare Bit?.........................................4 + 2.2 Opcode Assignment......................................4 + 2.3 RCODE Assignment.......................................5 + 3. DNS Resource Records....................................6 + 3.1 RR TYPE IANA Considerations............................7 + 3.1.1 DNS TYPE Allocation Policy...........................8 + 3.1.2 Special Note on the OPT RR...........................9 + 3.1.3 The AFSDB RR Subtype Field...........................9 + 3.2 RR CLASS IANA Considerations...........................9 + 3.3 RR NAME Considerations................................11 + 4. Security Considerations................................11 + + Appendix: Changes from RFC 2929...........................12 + + Copyright and Disclaimer..................................13 + Normative References......................................13 + Informative References....................................14 + + Authors Addresses.........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +1. Introduction + + The Domain Name System (DNS) provides replicated distributed secure + hierarchical databases which hierarchically store "resource records" + (RRs) under domain names. DNS data is structured into CLASSes and + zones which can be independently maintained. See [RFC 1034, 1035, + 2136, 2181, 4033] familiarity with which is assumed. + + This document provides, either directly or by reference, general IANA + parameter assignment considerations applying across DNS query and + response headers and all RRs. There may be additional IANA + considerations that apply to only a particular RR type or + query/response opcode. See the specific RFC defining that RR type or + query/response opcode for such considerations if they have been + defined, except for AFSDB RR considerations [RFC 1183] which are + included herein. This RFC obsoletes [RFC 2929]. + + IANA currently maintains a web page of DNS parameters. See + <http://www.iana.org/numbers.htm>. + + "IETF Standards Action", "IETF Consensus", "Specification Required", + and "Private Use" are as defined in [RFC 2434]. + + + +2. DNS Query/Response Headers + + The header for DNS queries and responses contains field/bits in the + following diagram taken from [RFC 2136, 2929]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The ID field identifies the query and is echoed in the response so + they can be matched. + + The QR bit indicates whether the header is for a query or a response. + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful + only in queries or only in responses, depending on the bit. However, + many DNS implementations copy the query header as the initial value + of the response header without clearing bits. Thus any attempt to + use a "query" bit with a different meaning in a response or to define + a query meaning for a "response" bit is dangerous given existing + implementation. Such meanings may only be assigned by an IETF + Standards Action. + + The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), + authority count (NSCOUNT), and additional information count (ARCOUNT) + express the number of records in each section for all opcodes except + Update. These fields have the same structure and data type for + Update but are instead the counts for the zone (ZOCOUNT), + prerequisite (PRCOUNT), update (UPCOUNT), and additional information + (ARCOUNT) sections. + + + +2.1 One Spare Bit? + + There have been ancient DNS implementations for which the Z bit being + on in a query meant that only a response from the primary server for + a zone is acceptable. It is believed that current DNS + implementations ignore this bit. + + Assigning a meaning to the Z bit requires an IETF Standards Action. + + + +2.2 Opcode Assignment + + Currently DNS OpCodes are assigned as follows: + + OpCode Name Reference + + 0 Query [RFC 1035] + 1 IQuery (Inverse Query, Obsolete) [RFC 3425] + 2 Status [RFC 1035] + 3 available for assignment + 4 Notify [RFC 1996] + 5 Update [RFC 2136] + 6-15 available for assignment + + New OpCode assignments require an IETF Standards Action as modified + by [RFC 4020]. + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +2.3 RCODE Assignment + + It would appear from the DNS header above that only four bits of + RCODE, or response/error code are available. However, RCODEs can + appear not only at the top level of a DNS response but also inside + OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. + The OPT RR provides an eight bit extension resulting in a 12 bit + RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. + + Error codes appearing in the DNS header and in these three RR types + all refer to the same error code space with the single exception of + error code 16 which has a different meaning in the OPT RR from its + meaning in other contexts. See table below. + + RCODE Name Description Reference + Decimal + Hexadecimal + 0 NoError No Error [RFC 1035] + 1 FormErr Format Error [RFC 1035] + 2 ServFail Server Failure [RFC 1035] + 3 NXDomain Non-Existent Domain [RFC 1035] + 4 NotImp Not Implemented [RFC 1035] + 5 Refused Query Refused [RFC 1035] + 6 YXDomain Name Exists when it should not [RFC 2136] + 7 YXRRSet RR Set Exists when it should not [RFC 2136] + 8 NXRRSet RR Set that should exist does not [RFC 2136] + 9 NotAuth Server Not Authoritative for zone [RFC 2136] + 10 NotZone Name not contained in zone [RFC 2136] + 11 - 15 Available for assignment + 16 BADVERS Bad OPT Version [RFC 2671] + 16 BADSIG TSIG Signature Failure [RFC 2845] + 17 BADKEY Key not recognized [RFC 2845] + 18 BADTIME Signature out of time window [RFC 2845] + 19 BADMODE Bad TKEY Mode [RPC 2930] + 20 BADNAME Duplicate key name [RPF 2930] + 21 BADALG Algorithm not supported [RPF 2930] + + 22 - 3,840 + 0x0016 - 0x0F00 Available for assignment + + 3,841 - 4,095 + 0x0F01 - 0x0FFF Private Use + + 4,096 - 65,534 + 0x1000 - 0xFFFE Available for assignment + + 65,535 + 0xFFFF Reserved, can only be allocated by an IETF + Standards Action. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Since it is important that RCODEs be understood for interoperability, + assignment of new RCODE listed above as "available for assignment" + requires an IETF Consensus. + + + +3. DNS Resource Records + + All RRs have the same top level format shown in the figure below + taken from [RFC 1035]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + NAME is an owner name, i.e., the name of the node to which this + resource record pertains. NAMEs are specific to a CLASS as described + in section 3.2. NAMEs consist of an ordered sequence of one or more + labels each of which has a label type [RFC 1035, 2671]. + + TYPE is a two octet unsigned integer containing one of the RR TYPE + codes. See section 3.1. + + CLASS is a two octet unsigned integer containing one of the RR CLASS + codes. See section 3.2. + + TTL is a four octet (32 bit) bit unsigned integer that specifies the + number of seconds that the resource record may be cached before the + source of the information should again be consulted. Zero is + interpreted to mean that the RR can only be used for the transaction + in progress. + + RDLENGTH is an unsigned 16 bit integer that specifies the length in + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + octets of the RDATA field. + + RDATA is a variable length string of octets that constitutes the + resource. The format of this information varies according to the TYPE + and in some cases the CLASS of the resource record. + + + +3.1 RR TYPE IANA Considerations + + There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, + and MetaTYPEs. + + Data TYPEs are the primary means of storing data. QTYPES can only be + used in queries. Meta-TYPEs designate transient data associated with + an particular DNS message and in some cases can also be used in + queries. Thus far, data TYPEs have been assigned from 1 upwards plus + the block from 100 through 103 while Q and Meta Types have been + assigned from 255 downwards except for the OPT Meta-RR which is + assigned TYPE 41. There have been DNS implementations which made + caching decisions based on the top bit of the bottom byte of the RR + TYPE. + + There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG + [RFC 2845], and TKEY [RFC 2930]. + + There are currently five QTYPEs assigned: * (all), MAILA, MAILB, + AXFR, and IXFR. + + Considerations for the allocation of new RR TYPEs are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC + 2535] and in other circumstances and must never be allocated + for ordinary use. + + 1 - 127 + 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data + TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + 128 - 255 + 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and + Meta TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + 256 - 32,767 + 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS + TYPE Allocation Policy as specified in section 3.1.1. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. + + 65,280 - 65534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + + +3.1.1 DNS TYPE Allocation Policy + + Parameter values specified above as assigned based on DNS TYPE + Allocation Policy. That is, Expert Review with the additional + requirement that the review be based on a complete template as + specified below which has been posted for three weeks to the + namedroppers@ops.ietf.org mailing list. + + Partial or draft templates may be posted with the intend of + soliciting feedback. + + + DNS RR TYPE PARAMETER ALLOCATION TEMPLATE + + Date: + + Name and email of originator: + + Pointer to internet-draft or other document giving a detailed + description of the protocol use of the new RR Type: + + What need is the new RR TYPE intended to fix? + + What existing RR TYPE(s) come closest to filling that need and why are + they unsatisfactory? + + Does the proposed RR TYPR require special handling within the DNS + different from an Unknown RR TYPE? + + Comments: + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.1.2 Special Note on the OPT RR + + The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its + primary purpose is to extend the effective field size of various DNS + fields including RCODE, label type, OpCode, flag bits, and RDATA + size. In particular, for resolvers and servers that recognize it, it + extends the RCODE field from 4 to 12 bits. + + + +3.1.3 The AFSDB RR Subtype Field + + The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same + RDATA field structure as the MX RR but the 16 bit unsigned integer + field at the beginning of the RDATA is interpreted as a subtype as + follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Allocation requires IETF Standards Action. + + 1 + 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. + + 2 + 0x0002 - DCE/NCA root cell directory node [RFC 1183]. + + 3 - 65,279 + 0x0003 - 0xFEFF - Allocation by IETF Consensus. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, allocation requires IETF Standards Action. + + + +3.2 RR CLASS IANA Considerations + + DNS CLASSes have been little used but constitute another dimension of + the DNS distributed database. In particular, there is no necessary + relationship between the name space or root servers for one CLASS and + those for another CLASS. The same name can have completely different + meanings in different CLASSes; however, the label types are the same + and the null label is usable only as root in every CLASS. However, + as global networking and DNS have evolved, the IN, or Internet, CLASS + has dominated DNS use. + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + There are two subcategories of DNS CLASSes: normal data containing + classes and QCLASSes that are only meaningful in queries or updates. + + The current CLASS assignments and considerations for future + assignments are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Reserved, assignment requires an IETF Standards Action. + + 1 + 0x0001 - Internet (IN). + + 2 + 0x0002 - Available for assignment by IETF Consensus as a data CLASS. + + 3 + 0x0003 - Chaos (CH) [Moon 1981]. + + 4 + 0x0004 - Hesiod (HS) [Dyer 1987]. + + 5 - 127 + 0x0005 - 0x007F - available for assignment by IETF Consensus for data + CLASSes only. + + 128 - 253 + 0x0080 - 0x00FD - available for assignment by IETF Consensus for + QCLASSes only. + + 254 + 0x00FE - QCLASS None [RFC 2136]. + + 255 + 0x00FF - QCLASS Any [RFC 1035]. + + 256 - 32,767 + 0x0100 - 0x7FFF - Assigned by IETF Consensus. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Assigned based on Specification Required as defined + in [RFC 2434]. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.3 RR NAME Considerations + + DNS NAMEs are sequences of labels [RFC 1035]. The last label in each + NAME is "ROOT" which is the zero length label. By definition, the + null or ROOT label can not be used for any other NAME purpose. + + At the present time, there are two categories of label types, data + labels and compression labels. Compression labels are pointers to + data labels elsewhere within an RR or DNS message and are intended to + shorten the wire encoding of NAMEs. The two existing data label + types are sometimes referred to as Text and Binary. Text labels can, + in fact, include any octet value including zero value octets but most + current uses involve only [US-ASCII]. For retrieval, Text labels are + defined to treat ASCII upper and lower case letter codes as matching + [insensitive]. Binary labels are bit sequences [RFC 2673]. The + Binary label type is Experimental [RFC 3363]. + + IANA considerations for label types are given in [RFC 2671]. + + NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon + 1981] CLASSes are essentially for local use. The IN or Internet + CLASS is thus the only DNS CLASS in global use on the Internet at + this time. + + A somewhat out-of-date description of name allocation in the IN Class + is given in [RFC 1591]. Some information on reserved top level + domain names is in BCP 32 [RFC 2606]. + + + +4. Security Considerations + + This document addresses IANA considerations in the allocation of + general DNS parameters, not security. See [RFC 4033, 4034, 4035] for + secure DNS considerations. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Appendix: Changes from RFC 2929 + + RFC Editor: This Appendix should be deleted for publication. + + Changes from RFC 2929 to this draft: + + 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE + Allocation Policy" and add the specification of that policy. Change + some remaining "IETF Standards Action" allocation requirements to say + "as modified by [RFC 4020]". + + 2. Updated various RFC references. + + 3. Mentioned that the Binary label type is now Experimental and + IQuery is Obsolete. + + 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be + IETF Standards Action required. + + 5. Add an IANA allocation policy for the AFSDB RR Subtype field. + + 6. Addition of reference to case insensitive draft. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. + Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. + + [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + +D. Eastlake 3rd [Page 13] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", September 2000. + + [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November + 2002. + + [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of + Standards Track Code Points", BCP 100, RFC 4020, February 2005. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + + +Informative References + + [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena + Technical Plan - Name Service, April 1987, + + [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts + Institute of Technology Artificial Intelligence Laboratory, June + 1981. + + [RFC 1591] - Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + + [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", RFC 2606, June 1999. + + [insensitive] - Eastlake, D., "Domain Name System (DNS) Case + + +D. Eastlake 3rd [Page 14] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, + work in progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 15] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Authors Addresses + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + email: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires February 2006. + + Its file name is draft-ietf-dnsext-2929bis-01.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt new file mode 100644 index 0000000..94c08ec --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-09.txt @@ -0,0 +1,992 @@ +INTERNET-DRAFT Edward Lewis +draft-ietf-dnsext-axfr-clarify-09.txt NeuStar, Inc. +DNSEXT WG July 2008 +Updates: 1034, 1035 (if approved) Intended status: Standards Track + + DNS Zone Transfer Protocol (AXFR) +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 31, 2008. + +Copyright Notice + +Copyright (C) The IETF Trust (2008). + +Abstract + +The Domain Name System standard mechanisms for maintaining coherent +servers for a zone consist of three elements. One mechanism is the +Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. +The definition of AXFR, has proven insufficient in detail, forcing +implementations intended to be compliant to make assumptions, impeding +interoperability. Yet today we have a satisfactory set of +implementations that do interoperate. This document is a new +definition of the AXFR, new in the sense that is it recording an +accurate definition of an interoperable AXFR mechanism. + +1 Introduction + +The Domain Name System standard facilities for maintaining coherent +servers for a zone consist of three elements. Authoritative +Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities" +[RFC1034] (referred to in this document as RFC 1034) and "Domain Names +- Implementation and Specification" [RFC1035] (aka RFC 1035). +Incremental Zone Transfer (IXFR) is defined in "Incremental Zone +Transfer in DNS" [RFC1995]. A mechanism for prompt notification of +zone changes (NOTIFY) is defined in "A Mechanism for Prompt +Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of +these mechanisms is to enable a set of DNS name servers to remain +coherently authoritative for a given zone. + +Comments on this draft ought to be addressed to the editor or to +namedroppers@ops.ietf.org. + +1.1 Definition of Terms + +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 "Key words for use in +RFCs to Indicate Requirement Levels" [BCP14]. + +"Newer"/"New" DNS and "older"/"old" DNS refers to implementations +written after and prior to the publication of this document. + +1.2 Scope + +In the greater context there are many ways to achieve coherency among +a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form +just one, the one defined in the RFCs cited. For example, there are +DNS implementations that assemble answers from data stored in +relational databases (as opposed to master files) relying on the +database's non-DNS means to synchronize the database instances. Some +of these non-DNS solutions interoperate in some fashion. As far as +it is known, AXFR, IXFR and NOTIFY are the only in-band mechanisms +that provide an interoperable solution to the desire for coherency +within the definition of DNS, they certainly are the only mechanisms +documented by the IETF. + +This document does not cover incoherent DNS situations. There are +applications of the DNS in which servers for a zone are designed to be +incoherent. For these configurations, a coherency mechanism as +described here would be unsuitable. + +"General purpose DNS implementation" refers to DNS software developed +for wide-spread use. This includes resolvers and servers freely +accessible as libraries and standalone processes. This also includes +proprietary implementations used only in support of DNS service +offerings. + +"Turnkey DNS implementation" refers to custom made, single use +implementations of DNS. Such implementations consist of software +that employs the DNS protocol message format yet do not conform to +the entire range of DNS functionality. + +A DNS implementation is not required to support AXFR, IXFR and NOTIFY. +A DNS implementation SHOULD have some means for maintaining name server +coherency. A general purpose DNS implementation SHOULD include AXFR +(and in the same vein IXFR and NOTIFY), but turnkey DNS implementations +MAY exist without AXFR. (An editorial note to readers of this section. +The mention of IXFR and NOTIFY is for context and illustration, this +document does not make any normative comments on those mechanisms.) + +1.3 Context + +Besides describing the mechanisms themselves, there is the context in +which they operate to consider. When AXFR, IXFR and NOTIFY were +defined, there was little consideration given to security and privacy +issues. Since the original definition of AXFR, new opinions have +appeared on the access to an entire zone's contents. In this document, +the basic mechanisms will be discussed separately from the permission +to use these mechanisms. + +1.4 Coverage + +This document concentrates on just the definition of AXFR. Any effort +to update the IXFR or NOTIFY mechanisms would be done in different +documents. This is not strictly a clarification of the definition in +RFC 1034 and RFC 1035. This document will update those sections, and +invalidate at least one part of that definition. The goal of this +document is to define AXFR as it exists, or is supposed to exist, +currently. + +1.4 Coverage and Relationship to Original AXFR Specification + +This document concentrates on just the definition of AXFR. Any effort +to update the IXFR or NOTIFY mechanisms would be done in different +documents. + +The original "specification" of the AXFR sub-protocol is scattered +through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 on page 5 +depicts the scenario for which AXFR has been designed. Section 4.3.5 +of RFC 1034 describes the zone synchronisation strategies in general +and rules for the invocation of a full zone transfer via AXFR; the +fifth paragraph of that section contains a very short sketch of the +AXFR protocol. Section 3.2.3 of RFC 1035 has assigned the code point +for the AXFR QTYPE (see section 2.1.2 below for more details). +Section 4.2 of RFC 1035 discusses the transport layer use of DNS and +shortly explains why UDP transport is deemed inappropriate for AXFR; +the last paragraph of Section 4.2.2 gives details for the TCP +connection management with AXFR. Finally, the second paragraph of +Section 6.3 in RFC 1035 mandates server behavior when zone data +changes occur during an ongoing zone transfer using AXFR. + +This document will update the specification of AXFR in fully +specifying the record formats and processing rules for AXFR, largely +expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing +the transport considerations for AXFR, thus amending Section 4.2.2 of +RFC 1035. Furthermore, it discusses backward compatibility issues +and provides policy/management considerations as well as specific +Security Considerations for AXFR. The goal of this document is to +define AXFR as it exists, or is supposed to exist, currently. + +2 AXFR Messages + +An AXFR message exchange (or session) consists of an AXFR query message +and a set of AXFR response messages. In this document, AXFR client is +the sender of the AXFR query and the AXFR server is the responder. +(Use of terms such as master, slave, primary, secondary are not +important to defining the AXFR exchange.) The reason for the imbalance +in number of messages derives from large zones whose contents cannot be +fit into the limited permissible size of a DNS message. + +An important aspect to keep in mind is that the definition of AXFR is +restricted to TCP [RFC0793]. The design of the AXFR process has +certain inherent features that are not easily ported to UDP [RFC0768]. + +The basic format of an AXFR message is the DNS message as defined in +RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: +- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] +- "Domain Name System (DNS) IANA Considerations" [RFC2929] +- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] +- "Extension Mechanisms for DNS (EDNS0)" [RFC2671] +- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] +- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] +- "Obsoleting IQUERY" [RFC3425] +- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] +- "Protocol Modifications for the DNS Security Extensions" [RFC4035] +- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] + +The upper limit on the permissible size of a DNS message over TCP is +defined in RFC 1035, section 4.2.2. Unlike DNS messages over UDP, +this limit is not changed by EDNS0. + +Field names used in this document will correspond to the names as they +appear in the IANA registry for DNS Header Flags [DNSFLGS]. + +2.1 AXFR query + +An AXFR query is sent by a client whenever there is a reason to ask. +This might be because of zone maintenance activities or as a result of +a command line request, say for debugging. + +2.1.1 Header Values + +These are the DNS message header values for an AXFR query. + +ID See note 2.1.1.a +QR MUST be 0 (Query) +OPCODE MUST be 0 (Standard Query) +AA See note 2.1.1.b +TC See note 2.1.1.b +RD See note 2.1.1.b +RA See note 2.1.1.b +Z See note 2.1.1.c +AD See note 2.1.1.b +CD See note 2.1.1.b +RCODE MUST be 0 (No error) +QDCOUNT MUST be 1 +ANCOUNT MUST be 0 +NSCOUNT MUST be 0 +ARCOUNT See note 2.1.1.d + +Note 2.1.1.a Set to any value that the client is not already using +with the same server. There is no specific means for selecting the +value in this field. (Recall that AXFR is done only via TCP +connections.) + +A server MUST reply using messages that use the same message ID to +allow a client to meaningfully have multiple AXFR queries outstanding. + +Note 2.1.1.b The value in this field has no meaning in the context of +AXFR query messages. For the client, it is RECOMMENDED that the +value be zero. The server MUST ignore this value. + +Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore +it. + +Note 2.1.1.d The client MUST set this field to be the number of +resource records appearing in the additional section. See Section +2.1.5 "Additional Section" for details. + +The value MAY be 0, 1 or 2. If it is 2, the additional +section MUST contain both an EDNS0 [RFC2671] OPT resource record and +a record carrying transaction integrity and authentication data, +currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the +value is 1, then the additional section MUST contain either only an +EDNS0 OPT resource record or a record carrying transaction integrity +and authentication data. If the value is 0, the additional section +MUST be empty. + +2.1.2 Query Section + +The Query section of the AXFR query MUST conform to section 4.1.2 of +RFC 1035, and contain the following values: + +QNAME the name of the zone requested +QTYPE AXFR(= 252), the pseudo-RR type for zone transfer [DNSVALS] +QCLASS the class of the zone requested + +2.1.3 Answer Section + +MUST be empty. + +2.1.4 Authority Section + +MUST be empty. + +2.1.5 Additional Section + +The client MAY include an EDNS0 OPT [RFC2671] resource record. If the +server has indicated that it does not support EDNS0, the client MUST +send this section without an EDNS0 OPT resource record if there is a +retry. Indication that a server does not support EDNS0 is not an +explicit element in the protocol, it is up to the client to interpret. +Most likely, the server will return a FORMERR which might be related to +the OPT resource record. + +The client MAY include a transaction integrity and authentication +resource record, currently a choice of TSIG [RFC2845] or SIG(0) +[RFC2931]. If the server has indicated that it does not recognize the +resource record, and that the error is indeed caused by the resource +record, the client probably ought not try again. Removing the security +data in the face of an obstacle ought to only be done with full +awareness of the implication of doing so. + +In general, if an AXFR client is aware that an AXFR server does not +support a particular mechanism, the client SHOULD NOT attempt to engage +the server using the mechanism (or at all). A client could become +aware of a server's abilities via a configuration setting or via some +other (as yet) undefined means. + +The range of permissible resource records that MAY appear in the +additional section might change over time. If either a change to an +existing resource record (like the OPT RR for EDNS0) is made or +a new additional section record is created, the new definitions ought +to include a discussion on the impact upon AXFR. Although this is not +predictale, future additional section residing records may have an +effect that is orthogonal to AXFR, so can ride through the session as +opaque data. In this case, a "wise" implementation ought to be able +to pass these records through without disruption. + +2.2 AXFR response + +The AXFR response will consist of 0 or more messages. A "0 message" +response is covered in section 2.2.1. + +An AXFR response that is transferring the zone's contents will consist +of a series (which could be a series of length 1) of DNS messages. +In such a series, the first message MUST begin with the SOA +resource record of the zone, the last message MUST conclude with the +same SOA resource record. Intermediate messages MUST NOT contain the +SOA resource record. The first message MUST copy the Query Section +from the corresponding AXFR query message in to the first response +message's query section. Subsequent messages MAY do the same. + +An AXFR response that is indicating an error MUST consist of a single +DNS message with the return code set to the appropriate value for the +condition encountered - once the error condition is detected. Such +a message MUST copy the AXFR query Query Section into its Query +Section. The inclusion of the terminating SOA resource record is not +necessary. + +An AXFR client might receive a number of AXFR response messages +free of an error condition before the message indicating an error +is received. But once an error is reported, the AXFR client can +assume that the error reporting message is the last. + +2.2.1 "0 Message" Response + +A legitimate "0 message" response, i.e., the client sees no response +whatsoever, is very exceptional and controversial. Unquestionably it +is unhealthy for there to be 0 responses in a protocol that is designed +around a query - response paradigm over an unreliable transport. The +lack of a response could be a sign of underlying network problems and +cause the protocol state machine to react accordingly. However, AXFR +uses TCP and not UDP, eliminating undetected network errors. + +A "0 message response" is reserved for situations in which the server +has a reason to suspect that the query is sent for the purpose of +abuse. Due to the use of this being so controversial, a "0 message +response" is not being defined as a legitimate part of the protocol +but the use of it is being acknowledge as a warning to AXFR client +implementations. Any earnest query has the expectation of some +response but may not get one. + +If an AXFR client sends a query on a TCP connection and the connection +is closed at any point, the AXFR client MUST consider the session +terminated. The message ID MAY be used again on a new connection, +even if the question and AXFR server are the same. Facing a dropped +connection a client SHOULD try to make some determination whether the +connection closure was the result of network activity or a decision +by the AXFR server. This determination is not an exact science. It +is up to the AXFR client implementor to react, but the reaction +SHOULD NOT be an endless cycle of retires nor an increasing (in +frequency) retry rate. + +An AXFR server implementor SHOULD take into consideration what this +dilemma described above when a connection is closed with an outstanding +query in the pipeline. For this reason, a server ought to reserve +this course of action for situations in which it believes beyond a +doubt that the AXFR client is attemping abusive behavior. + +2.2.2 Header Values + +ID See note 2.2.2.a +QR MUST be 1 (Response) +OPCODE MUST be 0 (Standard Query) +AA See note 2.2.2.b +TC MUST be 0 (Not truncated) +RD RECOMMENDED copy request's value, MAY be set to 0 +RA See note 2.2.2.c +Z See note 2.2.2.d +AD See note 2.2.2.e +CD See note 2.2.2.e +RCODE See note 2.2.2.f +QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all + following +ANCOUNT See note 2.2.2.g +NSCOUNT MUST be 0 +ARCOUNT See note 2.2.2.h + +Note 2.2.2.a Because some old implementations behave differently than +is now desired, the requirement on this field is stated in detail. +New DNS servers MUST set this field to the value of the AXFR query +ID in each AXFR response message for the session. AXFR clients MUST +be able to manage sessions resulting from the issuance of multiple +outstanding queries, whether AXFR queries or other DNS queries. A +client SHOULD discard responses that do not correspond (via the +message ID) to any outstanding queries. + +Unless the client is sure that the server will consistently set the ID +field to the query's ID, the client is NOT RECOMMENDED to issue any +other queries until the end of the zone transfer. A client MAY become +aware of a server's abilities via a configuration setting. + +Note 2.2.2.b If the RCODE is 0 (no error), then the AA bit MUST be 1. +For any other value of RCODE, the AA bit MUST be set according to rules +for that error code. If in doubt, it is RECOMMENDED that it be set +to 1. It is RECOMMENDED that the value be ignored by the AXFR client. + +Note 2.2.2.c It is RECOMMENDED that the server set the value to 0, +the client MUST ignore this value. + +The server MAY set this value according to the local policy regarding +recursive service, but doing so might confuse the interpretation of the +response as AXFR can not be retrieved recursively. A client MAY note +the server's policy regarding recursive service from this value, but +SHOULD NOT conclude that the AXFR response was obtained recursively +even if the RD bit was 1 in the query. + +Note 2.2.2.d The server MUST set this bit to 0, the client MUST ignore +it. + +Note 2.2.2.e If the implementation supports the DNS Security Extensions +(see below) then this value MUST be set according to the rules in RFC +4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response". +If the implementation does not support the DNS Security Extensions, +then this value MUST be set to 0 and MUST be ignored upon receipt. + +The DNS Security Extensions (DNSSEC) is defined in these base +documents: +- "DNS Security Introduction and Requirements" [RFC4033] +- "Resource Records for the DNS Security Extensions" [RFC4034] +- "Protocol Modifications for the DNS Security Extensions" [RFC4035] + +Note 2.2.2.f In the absence of an error, the server MUST set the value +of this field to NoError. If a server is not authoritative for the +queried zone, the server SHOULD set the value to NotAuth. (Reminder, +consult the appropriate IANA registry [DNSVALS].) If a client +receives any other value in response, it MUST act according to the +error. For example, a malformed AXFR query or the presence of an EDNS0 +OPT resource record sent to an old server will garner a FormErr value. +This value is not set as part of the AXFR response processing. The +same is true for other error-indicating values. + +Note 2.2.2.g The count of answer records MUST equal the number of +resource records in the AXFR Answer Section. When a server is aware +that a client will only accept one resource record per response +message, then the value MUST be 1. A server MAY be made aware of a +client's limitations via configuration data. + +Note 2.2.2.h The client MUST set this field to be the number of +resource records appearing in the additional section. See Section +2.1.5 "Additional Section" for details. + +2.2.3 Query Section + +In the first response message, this section MUST be copied from the +query. In subsequent messages this section MAY be copied from the +query, MAY be empty. The content of this section MAY be used to +determine the context of the message, that is, the name of the zone +being transferred. + +2.2.4 Answer Section + +MUST be populated with the zone contents. See later section on +encoding zone contents. + +2.2.5 Authority Section + +MUST be empty. + +2.2.5 Additional Section + +The contents of this section MUST follow the guidelines for EDNS0, +TSIG, SIG(0), or what ever other future record is possible here. The +contents of section 2.1.5 apply here as well. + +Note that TSIG and SIG(0), if in use, will treat each individual +AXFR response message within a session as a unit of data. That is, +each message will have a TSIG or SIG(0) (if in use) and the +crytpographic check will cover just that message. The same rule +will apply to future alternatives and documents covering them ought +to consider the impact on AXFR response messages. + +3 Zone Contents + +The objective of the AXFR session is to request and transfer the +contents of a zone. The objective is to permit the client to +reconstruct the zone as it exists at the server for the given zone +serial number. Over time the definition of a zone has evolved from a +static set of records to a dynamically updated set of records to a +continually regenerated set of records. + +3.1 Records to Include + +In the answer section of AXFR response messages the resource records +within a zone for the given serial number MUST appear. The definition +of what belongs in a zone is described in RFC 1034, Section 4.2, "How +the database is divided into zones", and in particular, section 4.2.1, +"Technical considerations". + +Unless the AXFR server knows that the AXFR client expects just one +resource record per AXFR response message, an AXFR server SHOULD +populate an AXFR response message with as many complete resource +records as will fit within a DNS message. + +Zones for which it is impractical to list the entire zones for a serial +number (because changes happen too quickly) are not suitable for AXFR +retrieval. + +3.2 Delegation Records + +In RFC 1034, section 4.2.1, this text appears (keep in mind that the +"should" in the quotation predates [BCP14], cf. section 1.1) "The RRs +that describe cuts ... should be exactly the same as the corresponding +RRs in the top node of the subzone." There has been some controversy +over this statement and the impact on which NS resource records are +included in a zone transfer. + +The phrase "that describe cuts" is a reference to the NS set and +applicable glue records. It does not mean that the cut points and the +apex resource records are identical. For example, the SOA resource +record is only found at the apex, as well as a slew of DNSSEC resource +records. There are also some DNSSEC resource record sets that are +explicitly different between the cut point and the apex. The +discussion here is restricted to just the NS resource record set and +glue as these "describe cuts." + +The issue is that in operations there are times when the NS resource +records for a zone might be different at a cut point in the parent and +at the apex of a zone. Sometimes this is the result of an error and +sometimes it is part of an ongoing change in name servers. The DNS +protocol is robust enough to overcome inconsistencies up to (but not +including) there being no parent indicated NS resource record +referencing a server that is able to serve the child zone. This +robustness is one quality that has fueled the success of the DNS. +Still, the inconsistency is a error state and steps need to be taken +to make it apparent (if it is unplanned) and to make it clear once +the inconsistency has been removed. + +Another issue is that the AXFR server could be authoritative for a +different set of zones than the AXFR client. It is possible that the +AXFR server be authoritative for both halves of an inconsistent cut +point and that the AXFR client is authoritative for just the parent of +the cut point. + +The question that arises is, when facing a situation in which a cut +point's NS resource records do not match the authoritative set, whether +an AXFR server responds with the NS resource record set that is in the +zone or is at the authoritative location. + +The AXFR response MUST contain the cut point NS resource record set +registered with the zone whether it agrees with the authoritative set +or not. "Registered with" can be widely interpreted to include data +residing in the zone file of the zone for the particular serial +number (in zone file environments) or as any data configured to be in +the zone (database), statically or dynamically. + +The reasons for this requirement are: + +1) The AXFR server might not be able to determine that there is an +inconsistency given local data, hence requiring consistency would mean +a lot more needed work and even network retrieval of data. An +authoritative server ought not be required to perform any queries. + +2) By transferring the inconsistent NS resource records from a server +that is authoritative for both the cut point and the apex to a client +that is not authoritative for both, the error is exposed. For example, +an authorized administrator can manually request the AXFR and inspect +the results to see the inconsistent records. (A server authoritative +for both halves would otherwise always answer from the more +authoritative set, concealing the error.) + +3) The inconsistent NS resource record set might indicate a problem +in a registration database. + +4) Beginning with an error state of two servers for a zone having +inconsistent zone contents for a given zone serial number, if a client +requests and recieves an IXFR transfer from one server followed by +another IXFR transfer from the other server, the client can encounter +an IXFR protocol error state where an attempt is made to incrementally +add a record that already exists or to delete a record that does not +exist. + +(Editorial note, the 4th reason was suggested, but I don't see how +it relates. A nudge for updated text on this.) + +3.3 Glue Records + +As quoted in the previous section, RFC 1034, section 4.2.1, provides +guidance and rationale for the inclusion of glue records as part of +an AXFR transfer. And, as also argued in the previous section of this +document, even when there is an inconsistency between the address in a +glue record and the authoritative copy of the name server's address, +the glue resource record that is registered as part of the zone for +that serial number is to be included. + +This applies for glue records for any address family. + +The AXFR response MUST contain the appropriate glue records as +registered with the zone. The interpretation of "registered with" +in the previous section applies here. Inconsistent glue records are +an operational matter. + +3.4 Name Compression + +Compression of names in DNS messages is described in RFC 1035, section +4.1.4, "Message compression". The issue highlighted here relates to a +comment made in RFC 1034, section 3.1, "Name space specifications and +terminology" which says "When you receive a domain name or label, you +should preserve its case." ("Should" in the quote predates [BCP14].) + +Name compression in an AXFR message MUST preserve the case of the +original domain name. That is, although when comparing a domain name, +"a" equals "A", when comparing for the purposes of message compression, +"a" is not equal to "A". Note that this is not the usual definition +of name comparison in the DNS protocol and represents a new +requirement on AXFR servers. + +Rules governing name compression of RDATA in an AXFR message MUST +abide by the specification in "Handling of Unknown DNS Resource Record +(RR) Types" [RFC3597], specifically, section 4 on "Domain Name +Compression." + +3.5 Occluded Names + +Dynamic Update [RFC2136] (and including DNAME [2672]) operations can +have a side effect of occluding names in a zone. The addition of a +delegation point via dynamic update will render all subordinate domain +names to be in a limbo, still part of the zone but not available for to +the look up process. The addition of a DNAME resource record set has +the same impact. The subordinate names are said to be "occluded." + +Occluded names MUST be included in AXFR responses. An AXFR client MUST +be able to identify and handle occluded names. The rationale for this +action is based on a speedy recovery if the dynamic update operation +was in error and is to be undone. + +4 Transport + +AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC +1034 that states: "Because accuracy is essential, TCP or some other +reliable protocol must be used for AXFR requests." The most common +scenario is for an AXFR client to open a TCP connection to the AXFR +server, send an AXFR query, receive the AXFR response, and then +close the connection. There are variations on this, such as a query +for the zone's SOA resource record first, and so on. + +Two issues have emerged since the original specification of AXFR. +One is that lack of specificity has yielded some implementations +that assume the TCP connection is dedicated to the single AXFR +session, which has led to implementation choices that prevent either +multiple concurrent zone transfers or the use of the open connection +for other queries. The other issue is the prospect of using UDP as a +transport has come to look promising because of trends in the past +two decades. + +Being able to have multiple concurrent zone transfers is considered +desirable by operators who have sets of name servers that are +authoritative for a common set of zones. It would be desirable +if the name server implementations did not have to wait for one +zone to transfer before the next could begin. The desire here is to +tighten the specification, not a change, but adding words to the +unclear areas, to define what is needed to permit two servers to +share a TCP connection among concurrent AXFR sessions. The challenge +is to design this in a way that can fall back to the old behavior if +either the AXFR client or AXFR server is incapable of performing +multiple concurrent AXFR sessions. + +With the addition of EDNS0 and applications which require many +small zones such as in web hosting and some ENUM scenarios, AXFR +sessions on UDP are now possible and desirable. However, there +are still some aspects of the AXFR session that are not easily +translated to UDP. This document leaves AXFR over UDP undefined. + +4.1 TCP + +In the original definition there is an implicit assumption (probably +unintentional) that a TCP connection is used for one and only one +AXFR session. This is evidenced in no requirement to copy neither +the Query Section nor the message ID in responses, no explicit +ordering information within the AXFR response messages and the lack +of an explicit notice indicating that a zone transfer continues in the +next message. + +The guidance given here is intended to enable better performance of +the AXFR exchange as well as guidelines on interactions with older +software. Better performance includes being able to multiplex DNS +message exchanges including zone transfer sessions. Guidelines for +interacting with older software are generally applicable to AXFR +clients as reversing the situation, older AXFR client and newer +AXFR server ought to induce the server to operate within the +specification for an older server. + +4.1.1 AXFR client TCP + +An AXFR client MAY request an connection to an AXFR server for any +reason. An AXFR client SHOULD close the connection when there is +no apparent need to use the connection for some time period. The +AXFR server ought not have to maintain idle connections, the burden +of connection closure ought to be on the client. Apparent need for +the connection is a judgement for the AXFR client and the DNS +client. If the connection is used for multiple sessions, or it is +known sessions will be coming or is there is other query/response +traffic on the open connection, that is "apparent need." + +An AXFR client MAY cancel delivery of a zone only by closing the +connection. However, this action will also cancel all other outstanding +activity using the connection. There is no other mechanism by which +an AXFR response can be cancelled. + +When a TCP connection is closed remotely (relative to the client), +whether by the AXFR server or due to a network event, the AXFR client +MUST cancel all outstanding sessions. Recovery from this situation +is not straightforward. If the disruption was a spurious event, +attempting to restart the connection would be proper. If the +disruption was caused by a medium or long term disruption, the AXFR +client would be wise to not spend too many resources trying to rebuild +the connection. Finally, if the connection was dropped because of a +policy at the AXFR server (as can be the case with older AXFR servers), +the AXFR client would be wise to not retry the connection. +Unfortunately, knowing which of the three cases above applies is not +clear (momentary disruption, failure, policy). + +An AXFR client MAY use an already opened TCP connection to start an +AXFR session. Using an existing open connection is RECOMMENDED over +opening a new connection. (Non-AXFR session traffic can also use an +open connection.) If in doing so the AXFR client realizes that +the responses cannot be properly differentiated (lack of matching +query IDs for example) or the connection is terminated for a remote +reason, then the AXFR client SHOULD not attempt to reuse an open +connection with the specific AXFR server until the AXFR server is +updated (which is of course, not an event captured in the DNS +protocol). + +4.1.2 AXFR server TCP + +An AXFR server MUST be able to handle multiple AXFR sessions on a +single TCP connection, as well as handle other query/response sessions. + +If a TCP connection is closed remotely, the AXFR server MUST cancel +all AXFR sessions in place. No retry activity is necessary, that is +initiated by the AXFR client. + +Local policy MAY dictate that a TCP connection is to be closed. Such +as action SHOULD be in reaction to limits such as those placed on +the number of outstanding open connections. Closing a connection in +response to a suspected security event SHOULD be done only in extreme +cases, when the server is certain the action is warranted. An +isolated request for a zone not on the AXFR server SHOULD receive +a response with the appropriate return code and not see the connection +broken. + +4.2 UDP + +AXFR sessions over UDP transport are not defined. + +5 Authorization + +A zone administrator has the option to restrict AXFR access to a zone. +This was not envisioned in the original design of the DNS but has +emerged as a requirement as the DNS has evolved. Restrictions on AXFR +could be for various reasons including a desire (or in some instances, +having a legal requirement) to keep the bulk version of the zone +concealed or to prevent the servers from handling the load incurred in +serving AXFR. All reasons are arguable, but the fact remains that +there is a requirement to provide mechanisms to restrict AXFR. + +A DNS implementation SHOULD provide means to restrict AXFR sessions to +specific clients. By default, a DNS implementation SHOULD only allow +the designated authoritative servers to have access to the zone. + +An implementation SHOULD allow access to be granted to Internet +Protocol addresses and ranges, regardless of whether a source address +could be spoofed. Combining this with techniques such as Virtual +Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be +effective. + +A general purpose implementation is RECOMMENDED to implement access +controls based upon "Secret Key Transaction Authentication for DNS" +[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" +[RFC2931]. + +A general purpose implementation SHOULD allow access to be open to +all AXFR requests. I.e., an operator ought to be able to allow any +AXFR query to be granted. + +A general purpose implementation SHOULD NOT have a default policy +for AXFR requests to be "open to all." + +6 Zone Integrity + +Ensuring that an AXFR client does not accept a forged copy of a zone is +important to the security of a zone. If a zone operator has the +opportunity, protection can be afforded via dedicated links, physical +or virtual via a VPN among the authoritative servers. But there are +instances in which zone operators have no choice but to run AXFR +sessions over the global public Internet. + +Besides best attempts at securing TCP sessions, DNS implementations +SHOULD provide means to make use of "Secret Key Transaction +Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction +Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the +contents. These techniques MAY also be used for authorization. + +7 Backwards Compatibility + +Describing backwards compatibility is difficult because of the lack of +specifics in the original definition. In this section some hints at +building in backwards compatibility are given, mostly repeated from the +earlier sections. + +Backwards compatibility is not necessary, but the greater extent of an +implementation's compatibility increases it's interoperability. For +turnkey implementations this is not usually a concern. For general +purpose implementations this takes on varying levels of importance +depending on the implementer's desire to maintain interoperability. + +It is unfortunate that a need to fall back to older behavior cannot be +discovered, hence needs to be noted in a configuration file. An +implementation SHOULD, in it's documentation, encourage operators to +periodically review AXFR clients and servers it has made notes about as +old software periodically gets updated. + +7.1 Server + +An AXFR server has the luxury of being able to react to an AXFR +client's abilities with the exception of knowing if the client can +accept multiple resource records per AXFR response message. The +knowledge that a client is so restricted apparently cannot be +discovered, hence it has to be set by configuration. + +An implementation of an AXFR server SHOULD permit configuring, on a per +AXFR client basis, a need to revert to single resource record per +message. The default SHOULD be to use multiple records per message. + +7.2 Client + +An AXFR client has the opportunity to try extensions when querying +an AXFR server. + +Attempting to issue multiple DNS queries over a TCP transport for an +AXFR session SHOULD be aborted if it interrupts the original request +and SHOULD take into consideration whether the AXFR server intends to +close the connection immediately upon completion of the original +(connection-causing) zone transfer. + +8 Security Considerations + +Concerns regarding authorization, traffic flooding, and message +integrity are mentioned in "Authorization" (section 5), "TCP" (section +4.2) and Zone Integrity (section 6). + +9 IANA Considerations + +No new registries or new registrations are included in this document. + +10 Internationalization Considerations + +It is assumed that supporting of international domain names has been +solved via "Internationalizing Domain Names in Applications (IDNA)" +[RFC3490]. + +11 Acknowledgements + +Earlier editions of this document have been edited by Andreas +Gustafsson. In his latest version, this acknowledgement appeared. + +"Many people have contributed input and commentary to earlier versions +of this document, including but not limited to Bob Halley, Dan +Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, +Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, +and Brian Wellington." + +Comments since the -05 version have come from these individuals: +Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain +Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, +... + +12 References + +All references prefixed by "RFC" can be obtained from the RFC Editor, +information regarding this organization can be found at the following +URL: + http://rfc-editor.org/ +Additionally, these documents can be obtained via the IETF web site. + +12.1 Normative + +[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + September 1981. +[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. +[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. +[RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. +[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. +[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. +[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC + 2136, April 1997. +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. +[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, + August 1999. +[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. +[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, RFC + 2929, September 2000. +[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. +[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. +[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002. +[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. +[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. +[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication + Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", + RFC 4635, August 2006. +[DNSFLGS] http://www.iana.org/assignments/dns-header-flags +[DNSVALS] http://www.iana.org/assignments/dns-parameters + +12.2 Informative + +[BCP14] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. +[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. + Malis, "A Framework for IP Based Virtual Private Networks", + RFC 2764, February 2000. +[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, + "Internationalizing Domain Names in Applications (IDNA)", RFC + 3490, March 2003. + +13 Editor's Address + +Edward Lewis +46000 Center Oak Plaza +Sterling, VA, 22033, US ++1-571-434-5468 +ed.lewis@neustar.biz + +Full Copyright Statement + +Copyright (C) The IETF Trust (2008). + +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, THE IETF TRUST AND +THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS +OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF +THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + +The IETF takes no position regarding the validity or scope of any +Intellectual Property Rights or other rights that might be claimed to +pertain to the implementation or use of the technology described in +this document or the extent to which any license under such rights +might or might not be available; nor does it represent that it has +made any independent effort to identify any such rights. Information +on the procedures with respect to rights in RFC documents can be +found in BCP 78 and BCP 79. + +Copies of IPR disclosures made to the IETF Secretariat and any +assurances of licenses to be made available, or the result of an +attempt made to obtain a general license or permission for the use of +such proprietary rights by implementers or users of this +specification can be obtained from the IETF on-line IPR repository at +http://www.ietf.org/ipr. + +The IETF invites any interested party to bring to its attention any +copyrights, patents or patent applications, or other proprietary +rights that may cover technology that may be required to implement +this standard. Please address the information to the IETF at +ietf-ipr@ietf.org. + +Acknowledgment + +Funding for the RFC Editor function is provided by the IETF +Administrative Support Activity (IASA). + + diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt new file mode 100644 index 0000000..438e800 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt @@ -0,0 +1,1397 @@ +DNS Extensions Working Group G. Sisson +Internet-Draft B. Laurie +Expires: January 11, 2006 Nominet + July 10, 2005 + + + Derivation of DNS Name Predecessor and Successor + draft-ietf-dnsext-dns-name-p-s-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 January 11, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes two methods for deriving the canonically- + ordered predecessor and successor of a DNS name. These methods may + be used for dynamic NSEC resource record synthesis, enabling + security-aware name servers to provide authenticated denial of + existence without disclosing other owner names in a DNSSEC-secured + zone. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 1] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 + 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4 + 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4 + 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6 + 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6 + 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7 + 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7 + 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8 + 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8 + 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8 + 5.4.2. Use of Modified Method With Zones Containing + SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.1. Examples of Immediate Predecessors Using Absolute + Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. Examples of Immediate Successors Using Absolute Method . . 13 + 6.3. Examples of Predecessors Using Modified Method . . . . . . 19 + 6.4. Examples of Successors Using Modified Method . . . . . . . 20 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22 + A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22 + A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23 + A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Intellectual Property and Copyright Statements . . . . . . . . . . 25 + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 2] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +1. Introduction + + One of the proposals for avoiding the exposure of zone information + during the deployment DNSSEC is dynamic NSEC resource record (RR) + synthesis. This technique is described in [I-D.ietf-dnsext-dnssec- + trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the + generation of NSEC RRs that just span the query name for non-existent + owner names. In order to do this, the DNS names which would occur + just prior to and just following a given query name must be + calculated in real time, as maintaining a list of all possible owner + names that might occur in a zone would be impracticable. + + Section 6.1 of [RFC4034] defines canonical DNS name order. This + document does not amend or modify this definition. However, the + derivation of immediate predecessor and successor, while trivial, is + non-obvious. Accordingly, several methods are described here as an + aid to implementors and a reference to other interested parties. + + This document describes two methods: + + 1. An ``absolute method'', which returns the immediate predecessor + or successor of a domain name such that no valid DNS name could + exist between that DNS name and the predecessor or successor. + + 2. A ``modified method'', which returns a predecessor and successor + which are more economical in size and computation. This method + is restricted to use with zones consisting only of single-label + owner names where a maximum-length owner name would not result in + a DNS name exceeding the maximum DNS name length. This is, + however, the type of zone for which the technique of online- + signing is most likely to be used. + + +2. Notational Conventions + + The following notational conventions are used in this document for + economy of expression: + + N: An unspecified DNS name. + + P(N): Immediate predecessor to N (absolute method). + + S(N): Immediate successor to N (absolute method). + + P'(N): Predecessor to N (modified method). + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 3] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + S'(N): Successor to N (modified method). + + +3. Absolute Method + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + +3.1. Derivation of DNS Name Predecessor + + To derive P(N): + + 1. If N is the same as the owner name of the zone apex, prepend N + repeatedly with labels of the maximum length possible consisting + of octets of the maximum sort value (e.g. 0xff) until N is the + maximum length possible; otherwise continue to the next step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g. 0x00), remove that + label; otherwise continue to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet and continue with step 5. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values that correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. Continue to the next step. + + 5. Prepend N repeatedly with labels of as long a length as possible + consisting of octets of the maximum sort value until N is the + maximum length possible. + +3.2. Derivation of DNS Name Successor + + To derive S(N): + + 1. If N is two or more octets shorter than the maximum DNS name + length, prepend N with a label containing a single octet of the + minimum sort value (e.g. 0x00); otherwise continue to the next + step. + + 2. If N is one or more octets shorter than the maximum DNS name + length and the least significant (left-most) label is one or more + octets shorter than the maximum label length, append an octet of + + + +Sisson & Laurie Expires January 11, 2006 [Page 4] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + the minimum sort value to the least significant label; otherwise + continue to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g. 0xff), skipping any values that + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then continue to the next step. + + 4. Remove the least significant (left-most) label. If N is now the + same as the owner name of the zone apex, do nothing. (This will + occur only if N is the maximum possible name in canonical DNS + name order, and thus has wrapped to the owner name of zone apex.) + Otherwise repeat starting at step 2. + + +4. Modified Method + + This method is for use with zones consisting only of single-label + owner names where an owner name consisting of label of maximum length + would not result in a DNS name which exceeded the maximum DNS name + length. This method is computationally simpler and returns values + which are more economical in size than the absolute method. It + differs from the absolute method detailed above in the following + ways: + + 1. Step 1 of the derivation P(N) has been omitted as the existence + of the owner name of the zone apex never requires denial. + + 2. A new step 1 has been introduced which removes unnecessary + labels. + + 3. Step 4 of the derivation P(N) has been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission generally results in a significant + reduction of the length of derived predecessors. + + 4. Step 1 of the derivation S(N) had been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission results in a tiny reduction of the + length of derived successors, and maintains consistency with the + modification of step 4 of the derivation P(N) described above. + + 5. Steps 2 and 4 of the derivation S(N) have been modified to + eliminate checks for maximum DNS name length, as it is an + assumption of this method that no DNS name in the zone can exceed + the maximum DNS name length. + + + +Sisson & Laurie Expires January 11, 2006 [Page 5] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + +4.1. Derivation of DNS Name Predecessor + + To derive P'(N): + + 1. If N has more labels than the number of labels in the owner name + of the apex + 1, repeatedly remove the least significant (left- + most) label until N has no more labels than the number of labels + in the owner name of the apex + 1; otherwise continue to next + step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g. 0x00), remove that + label; otherwise continue to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values which correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. + +4.2. Derivation of DNS Name Successor + + To derive S'(N): + + 1. If N has more labels than the number of labels in the owner name + of the apex + 1, repeatedly remove the least significant (left- + most) label until N has no more labels than the number of labels + in the owner name of the apex + 1. Continue to next step. + + 2. If the least significant (left-most) label of N is one or more + octets shorter than the maximum label length, append an octet of + the minimum sort value to the least significant label; otherwise + continue to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g. 0xff), skipping any values which + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then continue to the next step. + + + +Sisson & Laurie Expires January 11, 2006 [Page 6] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + 4. Remove the least significant (left-most) label. (This will occur + only if the least significant label is the maximum label length + and consists entirely of octets of the maximum sort value, and + thus has wrapped to the owner name of the zone apex.) + + +5. Notes + +5.1. Case Considerations + + Section 3.5 of [RFC1034] specifies that "while upper and lower case + letters are allowed in [DNS] names, no significance is attached to + the case". Additionally, Section 6.1 of [RFC4034] states that when + determining canonical DNS name order, "uppercase US-ASCII letters are + treated as if they were lowercase US-ASCII letters". Consequently, + values corresponding to US-ASCII uppercase letters must be skipped + when decrementing and incrementing octets in the derivations + described in Section 3.1 and Section 3.2. + + The following pseudo-code is illustrative: + + Decrement the value of an octet: + + if (octet == '[') // '[' is just after uppercase 'Z' + octet = '@'; // '@' is just prior to uppercase 'A' + else + octet--; + + Increment the value of an octet: + + if (octet == '@') // '@' is just prior to uppercase 'A' + octet = '['; // '[' is just after uppercase 'Z' + else + octet++; + +5.2. Choice of Range + + [RFC2181] makes the clarification that "any binary string whatever + can be used as the label of any resource record". Consequently the + minimum sort value may be set as 0x00 and the maximum sort value as + 0xff, and the range of possible values will be any DNS name which + contains octets of any value other than those corresponding to + uppercase US-ASCII letters. + + However, if all owner names in a zone are in the letter-digit-hyphen, + or LDH, format specified in [RFC1034], it may be desirable to + restrict the range of possible values to DNS names containing only + LDH values. This has the effect of: + + + +Sisson & Laurie Expires January 11, 2006 [Page 7] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + 1. making the output of tools such as `dig' and `nslookup' less + subject to confusion; + + 2. minimising the impact that NSEC RRs containing DNS names with + non-LDH values (or non-printable values) might have on faulty DNS + resolver implementations; and + + 3. preventing the possibility of results which are wildcard DNS + names (see Section 5.3). + + This may be accomplished by using a minimum sort value of 0x1f (US- + ASCII character `-') and a maximum sort value of 0x7a (US-ASCII + character lowercase `z'), and then skipping non-LDH, non-lowercase + values when incrementing or decrementing octets. + +5.3. Wild Card Considerations + + Neither derivation avoids the possibility that the result may be a + DNS name containing a wildcard label, i.e. a label containing a + single octet with the value 0x2a (US-ASCII character `*'). With + additional tests, wildcard DNS names may be explicitly avoided; + alternatively, if the range of octet values can be restricted to + those corresponding to letter-digit-hyphen, or LDH, characters (see + Section 5.2), such DNS names will not occur. + + Note that it is improbable that a result which is a wildcard DNS name + will occur unintentionally; even if one does occur either as the + owner name of, or in the RDATA of an NSEC RR, it is treated as a + literal DNS name with no special meaning. + +5.4. Possible Modifications + +5.4.1. Restriction of Effective Maximum DNS Name Length + + [RFC1034] specifies that "the total number of octets that represent a + [DNS] name (i.e., the sum of all label octets and label lengths) is + limited to 255", including the null (zero-length) label which + represents the root. For the purpose of deriving predecessors and + successors during NSEC RR synthesis, the maximum DNS name length may + be effectively restricted to the length of the longest DNS name in + the zone. This will minimise the size of responses containing + synthesised NSEC RRs but, especially in the case of the modified + method, may result in some additional computational complexity. + + Note that this modification will have the effect of revealing + information about the longest name in the zone. Moreover, when the + contents of the zone changes, e.g. during dynamic updates and zone + transfers, care must be taken to ensure that the effective maximum + + + +Sisson & Laurie Expires January 11, 2006 [Page 8] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + DNS name length agrees with the new contents. + +5.4.2. Use of Modified Method With Zones Containing SRV RRs + + Normally the modified method cannot be used in zones that contain + SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple + labels. However the use of SRV RRs can be accommodated by various + techniques. There are at least four possible ways to do this: + + 1. Use conventional NSEC RRs for the region of the zone that + contains first-level labels beginning with the underscore (`_') + character. For the purposes of generating these NSEC RRs, the + existence of (possibly fictional) ownernames `9{63}' and `a' + could be assumed, providing a lower and upper bound for this + region. Then all queries where the QNAME doesn't exist but + contains a first-level label beginning with an underscore could + be handled using the normal DNSSEC protocol. + + This approach would make it possible to enumerate all DNS names + in the zone containing a first-level label beginning with + underscore, including all SRV RRs, but this may be of less a + concern to the zone administrator than incurring the overhead of + the absolute method or of the following variants of the modified + method. + + 2. The absolute method could be used for synthesising NSEC RRs for + all queries where the QNAME contains a leading underscore. + However this re-introduces the susceptibility of the absolute + method to denial of service activity, as an attacker could send + queries for an effectively inexhaustible supply of domain names + beginning with a leading underscore. + + 3. A variant of the modified method could be used for synthesising + NSEC RRs for all queries where the QNAME contains a leading + underscore. This variant would assume that all predecessors and + successors to queries where the QNAME contains a leading + underscore may consist of two lablels rather than only one. This + introduces a little additional complexity without incurring the + full increase in response size and computational complexity as + the absolute method. + + 4. Finally, a variant the modified method which assumes that all + owner names in the zone consist of one or two labels could be + used. However this negates much of the reduction in response + size of the modified method and may be nearly as computationally + complex as the absolute method. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 9] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +6. Examples + + In the following examples: + + the owner name of the zone apex is "example.com."; + + the range of octet values is 0x00 - 0xff excluding values + corresponding to uppercase US-ASCII letters; and + + non-printable octet values are expressed as three-digit decimal + numbers preceded by a backslash (as specified in Section 5.1 of + [RFC1035]). + +6.1. Examples of Immediate Predecessors Using Absolute Method + + Example of typical case: + + P(foo.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.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. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 10] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where least significant (left-most) label of DNS name + consists of a single octet of the minimum sort value: + + P(\000.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P(foo\000.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.foo.example.com. + + or, in alternate notation: + + \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 11] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name contains an octet which must be decremented by + skipping values corresponding to US-ASCII uppercase letters: + + P(fo\[.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fo\@\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\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. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 12] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\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. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + +6.2. Examples of Immediate Successors Using Absolute Method + + Example of typical case: + + S(foo.example.com.) = \000.foo.example.com. + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 13] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is one octet short of the maximum DNS name + length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + .ooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooo.ooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooo.ooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{47}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \000.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + fo{47}\000.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 14] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + o.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{48}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + p.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{47}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 15] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and the least + significant (left-most) label has the maximum sort value: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + \255{49}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooop.oooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooo.oooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooooooooo. + example.com. + + or, in alternate notation: + + o{62}p.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 16] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and the eight + least significant (right-most) octets of the least significant (left- + most) label have the maximum sort value: + + N = foooooooooooooooooooooooooooooooooooooooo\255 + \255\255\255\255\255\255\255.ooooooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooo.ooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooo.ooooooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooop.oooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + ooooooooo.oooooooooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooo.oooooooooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{39}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 17] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name is the maximum DNS name length and contains an + octet which must be incremented by skipping values corresponding to + US-ASCII uppercase letters: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + \@.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\@.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \[.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\[.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 18] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name has the maximum possible sort order in the + zone, and consequently wraps to the owner name of the zone apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\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. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + + S(N) = example.com. + +6.3. Examples of Predecessors Using Modified Method + + Example of typical case: + + P'(foo.example.com.) = + + 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. + + or, in alternate notation: + + fon\255{60}.example.com. + + + + +Sisson & Laurie Expires January 11, 2006 [Page 19] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where DNS name contains more labels than DNS names in the + zone: + + P'(bar.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P'(foo\000.example.com.) = foo.example.com. + + Example where least significant (left-most) label has the minimum + sort value: + + P'(\000.example.com.) = example.com. + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P'(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\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. + + or, in alternate notation: + + \255{63}.example.com. + +6.4. Examples of Successors Using Modified Method + + Example of typical case: + + S'(foo.example.com.) = foo\000.example.com. + + Example where DNS name contains more labels than DNS names in the + zone: + + S'(bar.foo.example.com.) = foo\000.example.com. + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 20] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + + Example where least significant (left-most) label has the maximum + sort value, and consequently wraps to the owner name of the zone + apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\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. + + or, in alternate notation: + + \255{63}.example.com. + + S'(N) = example.com. + + +7. Security Considerations + + The derivation of some predecessors/successors requires the testing + of more conditions than others. Consequently the effectiveness of a + denial-of-service attack may be enhanced by sending queries that + require more conditions to be tested. The modified method involves + the testing of fewer conditions than the absolute method and + consequently is somewhat less susceptible to this exposure. + + +8. IANA Considerations + + This document has no IANA actions. + + Note to RFC Editor: This section is included to make it clear during + pre-publication review that this document has no IANA actions. It + may therefore be removed should it be published as an RFC. + + +9. Acknowledgments + + The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and + Niall O'Reilly for their review and input. + + +10. References + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 21] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +10.1 Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + +10.2 Informative References + + [I-D.ietf-dnsext-dnssec-online-signing] + Ihren, J. and S. Weiler, "Minimally Covering NSEC Records + and DNSSEC On-line Signing", + draft-ietf-dnsext-dnssec-online-signing-00 (work in + progress), May 2005. + + [I-D.ietf-dnsext-dnssec-trans] + Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC + Transition Mechanisms", + draft-ietf-dnsext-dnssec-trans-02 (work in progress), + February 2005. + + +Appendix A. Change History + +A.1. Changes from sisson-02 to ietf-00 + + o Added notes on use of SRV RRs with modified method. + + o Changed reference from weiler-dnssec-online-signing to ietf- + dnsext-dnssec-online-signing. + + o Changed reference from ietf-dnsext-dnssec-records to RFC 4034. + + o Miscellaneous minor changes to text. + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 22] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +A.2. Changes from sisson-01 to sisson-02 + + o Added modified version of derivation (with supporting examples). + + o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N). + + o Added clarification to derivations about when processing stops. + + o Miscellaneous minor changes to text. + +A.3. Changes from sisson-00 to sisson-01 + + o Split step 3 of derivation of DNS name predecessor into two + distinct steps for clarity. + + o Added clarifying text and examples related to the requirement to + avoid uppercase characters when decrementing or incrementing + octets. + + o Added optimisation using restriction of effective maximum DNS name + length. + + o Changed examples to use decimal rather than octal notation as per + [RFC1035]. + + o Corrected DNS name length of some examples. + + o Added reference to weiler-dnssec-online-signing. + + o Miscellaneous minor changes to text. + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 23] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Authors' Addresses + + Geoffrey Sisson + Nominet + Sandford Gate + Sandy Lane West + Oxford + OX4 6LB + GB + + Phone: +44 1865 332339 + Email: geoff@nominet.org.uk + + + Ben Laurie + Nominet + 17 Perryn Road + London + W3 7LR + GB + + Phone: +44 20 8735 0686 + Email: ben@algroup.co.uk + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Expires January 11, 2006 [Page 24] + +Internet-Draft DNS Name Predecessor and Successor July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Sisson & Laurie Expires January 11, 2006 [Page 25] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt new file mode 100644 index 0000000..bcc2b4e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt @@ -0,0 +1,442 @@ + + +INTERNET-DRAFT Samuel Weiler +Expires: June 2004 December 15, 2003 +Updates: RFC 2535, [DS] + + Legacy Resolver Compatibility for Delegation Signer + draft-ietf-dnsext-dnssec-2535typecode-change-06.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Comments should be sent to the author or to the DNSEXT WG mailing + list: namedroppers@ops.ietf.org + +Abstract + + As the DNS Security (DNSSEC) specifications have evolved, the + syntax and semantics of the DNSSEC resource records (RRs) have + changed. Many deployed nameservers understand variants of these + semantics. Dangerous interactions can occur when a resolver that + understands an earlier version of these semantics queries an + authoritative server that understands the new delegation signer + semantics, including at least one failure scenario that will cause + an unsecured zone to be unresolvable. This document changes the + type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to + avoid those interactions. + +Changes between 05 and 06: + + Signifigantly reworked the IANA section -- went back to one + algorithm registry. + + Removed Diffie-Hellman from the list of zone-signing algorithms + (leaving only DSA, RSA/SHA-1, and private algorithms). + + Added a DNSKEY flags field registry. + +Changes between 04 and 05: + + IESG approved publication. + + Cleaned up an internal reference in the acknowledgements section. + + Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference. + + Changed the names of both new registries. Added algorithm + mnemonics to the new zone signing algorithm registry. Minor + rewording in the IANA section for clarity. + + Cleaned up formatting of references. Replaced unknown-rr draft + references with RFC3597. Bumped DS version number. + +Changes between 03 and 04: + + Clarified that RRSIG(0) may be defined by standards action. + + Created a new algorithm registry and renamed the old algorithm + registry for SIG(0) only. Added references to the appropriate + crypto algorithm and format specifications. + + Several minor rephrasings. + +Changes between 02 and 03: + + KEY (as well as SIG) retained for SIG(0) use only. + +Changes between 01 and 02: + + SIG(0) still uses SIG, not RRSIG. Added 2931 reference. + + Domain names embedded in NSECs and RRSIGs are not compressible and + are not downcased. Added unknown-rrs reference (as informative). + + Simplified the last paragraph of section 3 (NSEC doesn't always + signal a negative answer). + + Changed the suggested type code assignments. + + Added 2119 reference. + + Added definitions of "unsecure delegation" and "unsecure referral", + since they're not clearly defined elsewhere. + + Moved 2065 to informative references, not normative. + +1. Introduction + + The DNSSEC protocol has been through many iterations whose syntax + and semantics are not completely compatible. This has occurred as + part of the ordinary process of proposing a protocol, implementing + it, testing it in the increasingly complex and diverse environment + of the Internet, and refining the definitions of the initial + Proposed Standard. In the case of DNSSEC, the process has been + complicated by DNS's criticality and wide deployment and the need + to add security while minimizing daily operational complexity. + + A weak area for previous DNS specifications has been lack of detail + in specifying resolver behavior, leaving implementors largely on + their own to determine many details of resolver function. This, + combined with the number of iterations the DNSSEC spec has been + through, has resulted in fielded code with a wide variety of + behaviors. This variety makes it difficult to predict how a + protocol change will be handled by all deployed resolvers. The + risk that a change will cause unacceptable or even catastrophic + failures makes it difficult to design and deploy a protocol change. + One strategy for managing that risk is to structure protocol + changes so that existing resolvers can completely ignore input that + might confuse them or trigger undesirable failure modes. + + This document addresses a specific problem caused by Delegation + Signer's [DS] introduction of new semantics for the NXT RR that are + incompatible with the semantics in RFC 2535 [RFC2535]. Answers + provided by DS-aware servers can trigger an unacceptable failure + mode in some resolvers that implement RFC 2535, which provides a + great disincentive to sign zones with DS. The changes defined in + this document allow for the incremental deployment of DS. + +1.1 Terminology + + In this document, the term "unsecure delegation" means any + delegation for which no DS record appears at the parent. An + "unsecure referral" is an answer from the parent containing an NS + RRset and a proof that no DS record exists for that name. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2 The Problem + + Delegation Signer introduces new semantics for the NXT RR that are + incompatible with the semantics in RFC 2535. In RFC 2535, NXT + records were only required to be returned as part of a + non-existence proof. With DS, an unsecure referral returns, in + addition to the NS, a proof of non-existence of a DS RR in the form + of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was + to interpret a response with both an NS and an NXT in the authority + section, RCODE=0, and AA=0. Some widely deployed 2535-aware + resolvers interpret any answer with an NXT as a proof of + non-existence of the requested record. This results in unsecure + delegations being invisible to 2535-aware resolvers and violates + the basic architectural principle that DNSSEC must do no harm -- + the signing of zones must not prevent the resolution of unsecured + delegations. + +2. Possible Solutions + + This section presents several solutions that were considered. + Section 3 describes the one selected. + +2.1. Change SIG, KEY, and NXT type codes + + To avoid the problem described above, legacy (RFC2535-aware) + resolvers need to be kept from seeing unsecure referrals that + include NXT records in the authority section. The simplest way to + do that is to change the type codes for SIG, KEY, and NXT. + + The obvious drawback to this is that new resolvers will not be able + to validate zones signed with the old RRs. This problem already + exists, however, because of the changes made by DS, and resolvers + that understand the old RRs (and have compatibility issues with DS) + are far more prevalent than 2535-signed zones. + +2.2. Change a subset of type codes + + The observed problem with unsecure referrals could be addressed by + changing only the NXT type code or another subset of the type codes + that includes NXT. This has the virtue of apparent simplicity, but + it risks introducing new problems or not going far enough. It's + quite possible that more incompatibilities exist between DS and + earlier semantics. Legacy resolvers may also be confused by seeing + records they recognize (SIG and KEY) while being unable to find + NXTs. Although it may seem unnecessary to fix that which is not + obviously broken, it's far cleaner to change all of the type codes + at once. This will leave legacy resolvers and tools completely + blinded to DNSSEC -- they will see only unknown RRs. + +2.3. Replace the DO bit + + Another way to keep legacy resolvers from ever seeing DNSSEC + records with DS semantics is to have authoritative servers only + send that data to DS-aware resolvers. It's been proposed that + assigning a new EDNS0 flag bit to signal DS-awareness (tentatively + called "DA"), and having authoritative servers send DNSSEC data + only in response to queries with the DA bit set, would accomplish + this. This bit would presumably supplant the DO bit described in + RFC 3225. + + This solution is sufficient only if all 2535-aware resolvers zero + out EDNS0 flags that they don't understand. If one passed through + the DA bit unchanged, it would still see the new semantics, and it + would probably fail to see unsecure delegations. Since it's + impractical to know how every DNS implementation handles unknown + EDNS0 flags, this is not a universal solution. It could, though, + be considered in addition to changing the RR type codes. + +2.4. Increment the EDNS version + + Another possible solution is to increment the EDNS version number + as defined in RFC 2671 [RFC2671], on the assumption that all + existing implementations will reject higher versions than they + support, and retain the DO bit as the signal for DNSSEC awareness. + This approach has not been tested. + +2.5. Do nothing + + There is a large deployed base of DNS resolvers that understand + DNSSEC as defined by the standards track RFC 2535 and RFC 2065 + and, due to under specification in those documents, interpret any + answer with an NXT as a non-existence proof. So long as that is + the case, zone owners will have a strong incentive to not sign any + zones that contain unsecure delegations, lest those delegations be + invisible to such a large installed base. This will dramatically + slow DNSSEC adoption. + + Unfortunately, without signed zones there's no clear incentive for + operators of resolvers to upgrade their software to support the new + version of DNSSEC, as defined in [DS]. Historical data suggests + that resolvers are rarely upgraded, and that old nameserver code + never dies. + + Rather than wait years for resolvers to be upgraded through natural + processes before signing zones with unsecure delegations, + addressing this problem with a protocol change will immediately + remove the disincentive for signing zones and allow widespread + deployment of DNSSEC. + +3. Protocol changes + + This document changes the type codes of SIG, KEY, and NXT. This + approach is the cleanest and safest of those discussed above, + largely because the behavior of resolvers that receive unknown type + codes is well understood. This approach has also received the most + testing. + + To avoid operational confusion, it's also necessary to change the + mnemonics for these RRs. DNSKEY will be the replacement for KEY, + with the mnemonic indicating that these keys are not for + application use, per [RFC3445]. RRSIG (Resource Record SIGnature) + will replace SIG, and NSEC (Next SECure) will replace NXT. These + new types completely replace the old types, except that SIG(0) + [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. + + The new types will have exactly the same syntax and semantics as + specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for + the following: + + 1) Consistent with [RFC3597], domain names embedded in + RRSIG and NSEC RRs MUST NOT be compressed, + + 2) Embedded domain names in RRSIG and NSEC RRs are not downcased + for purposes of DNSSEC canonical form and ordering nor for + equality comparison, and + + 3) An RRSIG with a type-covered field of zero has undefined + semantics. The meaning of such a resource record may only be + defined by IETF Standards Action. + + If a resolver receives the old types, it SHOULD treat them as + unknown RRs and SHOULD NOT assign any special meaning to them or + give them any special treatment. It MUST NOT use them for DNSSEC + validations or other DNS operational decision making. For example, + a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to + validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, + they MUST NOT receive special treatment. As an example, if a SIG + is included in a signed zone, there MUST be an RRSIG for it. + Authoritative servers may wish to give error messages when loading + zones containing SIG or NXT records (KEY records may be included + for SIG(0) or TKEY). + + As a clarification to previous documents, some positive responses, + particularly wildcard proofs and unsecure referrals, will contain + NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as + negative answers merely because they contain an NSEC. + +4. IANA Considerations + +4.1 DNS Resource Record Types + + This document updates the IANA registry for DNS Resource Record + Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and + DNSKEY RRs, respectively. + + Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and + TKEY [RFC2930] use only. + + Type 30 (NXT) should be marked as Obsolete. + +4.2 DNS Security Algorithm Numbers + + To allow zone signing (DNSSEC) and transaction security mechanisms + (SIG(0) and TKEY) to use different sets of algorithms, the existing + "DNS Security Algorithm Numbers" registry is modified to include + the applicability of each algorithm. Specifically, two new columns + are added to the registry, showing whether each algorithm may be + used for zone signing, transaction security mechanisms, or both. + Only algorithms usable for zone signing may be used in DNSKEY, + RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG + may be used in SIG and KEY RRs. + + All currently defined algorithms remain usable for transaction + security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private + algorithms (types 253 and 254) may be used for zone signing. Note + that the registry does not contain the requirement level of each + algorithm, only whether or not an algorithm may be used for the + given purposes. For example, RSA/MD5, while allowed for + transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. + + Additionally, the presentation format algorithm mnemonics from + RFC2535 Section 7 are added to the registry. This document assigns + RSA/SHA-1 the mnemonic RSASHA1. + + As before, assignment of new algorithms in this registry requires + IETF Standards Action. Additionally, modification of algorithm + mnemonics or applicability requires IETF Standards Action. + Documents defining a new algorithm must address the applicability + of the algorithm and should assign a presentation mnemonic to the + algorithm. + +4.3 DNSKEY Flags + + Like the KEY resource record, DNSKEY contains a 16-bit flags field. + This document creates a new registry for the DNSKEY flags field. + + Initially, this registry only contains an assignment for bit 7 (the + ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF + Standards Action. + +4.4 DNSKEY Protocol Octet + + Like the KEY resource record, DNSKEY contains an eight bit protocol + field. The only defined value for this field is 3 (DNSSEC). No + other values are allowed, hence no IANA registry is needed for this + field. + +5. Security Considerations + + The changes introduced here do not materially affect security. + The implications of trying to use both new and legacy types + together are not well understood, and attempts to do so would + probably lead to unintended and dangerous results. + + Changing type codes will leave code paths in legacy resolvers that + are never exercised. Unexercised code paths are a frequent source + of security holes, largely because those code paths do not get + frequent scrutiny. + + Doing nothing, as described in section 2.5, will slow DNSSEC + deployment. While this does not decrease security, it also fails + to increase it. + +6. Normative references + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [DS] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15.txt, work in + progress, June 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2436, March 1999. + + [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. + +7. Informative References + + [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource + Record (RR) Types", RFC 3597, September 2003. + +8. Acknowledgments + + The changes introduced here and the analysis of alternatives had + many contributors. With apologies to anyone overlooked, those + include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed + Lewis, Bill Manning, and Suzanne Woolf. + + Thanks to Jakob Schlyter and Mark Andrews for identifying the + incompatibility described in section 1.2. + + In addition to the above, the author would like to thank Scott + Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive + comments. + +9. Author's Address + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + weiler@tislabs.com + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt new file mode 100644 index 0000000..3a800f9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt @@ -0,0 +1,616 @@ + + + +Network Working Group S. Weiler +Internet-Draft SPARTA, Inc +Updates: 4034, 4035 (if approved) May 23, 2005 +Expires: November 24, 2005 + + + Clarifications and Implementation Notes for DNSSECbis + draft-ietf-dnsext-dnssec-bis-updates-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 November 24, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is a collection of minor technical clarifications to + the DNSSECbis document set. It is meant to serve as a resource to + implementors as well as an interim repository of possible DNSSECbis + errata. + + + + + + + +Weiler Expires November 24, 2005 [Page 1] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Proposed additions in future versions + + An index sorted by the section of DNSSECbis being clarified. + + A list of proposed protocol changes being made in other documents, + such as NSEC3 and Epsilon. This document would not make those + changes, merely provide an index into the documents that are making + changes. + +Changes between -00 and -01 + + Document significantly restructured. + + Added section on QTYPE=ANY. + +Changes between personal submission and first WG draft + + Added Section 2.1 based on namedroppers discussions from March 9-10, + 2005. + + Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2. + + Added the DNSSECbis RFC numbers. + + Figured out the confusion in Section 4.1. + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 2] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Table of Contents + + 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 + 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 + 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4 + 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5 + 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5 + 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 + 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 + 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 + 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6 + 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 + 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7 + 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7 + 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7 + 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8 + 7.2 Informative References . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . . 11 + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 3] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +1. Introduction and Terminology + + This document lists some minor clarifications and corrections to + DNSSECbis, as described in [1], [2], and [3]. + + It is intended to serve as a resource for implementors and as a + repository of items that need to be addressed when advancing the + DNSSECbis documents from Proposed Standard to Draft Standard. + + In this version (-01 of the WG document), feedback is particularly + solicited on the structure of the document and whether the text in + the recently added sections is correct and sufficient. + + Proposed substantive additions to this document should be sent to the + namedroppers mailing list as well as to the editor of this document. + The editor would greatly prefer text suitable for direct inclusion in + this document. + +1.1 Structure of this Document + + The clarifications to DNSSECbis are sorted according to the editor's + impression of their importance, starting with ones which could, if + ignored, lead to security and stability problems and progressing down + to clarifications that are likely to have little operational impact. + Mere typos and awkward phrasings are not addressed unless they could + lead to misinterpretation of the DNSSECbis documents. + +1.2 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 [4]. + +2. Significant Concerns + + This section provides clarifications that, if overlooked, could lead + to security issues or major interoperability problems. + +2.1 Clarifications on Non-Existence Proofs + + RFC4035 Section 5.4 slightly underspecifies the algorithm for + checking non-existence proofs. In particular, the algorithm there + might incorrectly allow the NSEC from the parent side of a zone cut + to prove the non-existence of either other RRs at that name in the + child zone or other names in the child zone. It might also allow a + NSEC at the same name as a DNAME to prove the non-existence of names + beneath that DNAME. + + + + +Weiler Expires November 24, 2005 [Page 4] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + A parent-side delegation NSEC (one with the NS bit set, but no SOA + bit set, and with a singer field that's shorter than the owner name) + must not be used to assume non-existence of any RRs below that zone + cut (both RRs at that ownername and at ownernames with more leading + labels, no matter their content). Similarly, an NSEC with the DNAME + bit set must not be used to assume the non-existence of any + descendant of that NSEC's owner name. + +2.2 Empty Non-Terminal Proofs + + To be written, based on Roy Arends' May 11th message to namedroppers. + +2.3 Validating Responses to an ANY Query + + RFC4035 does not address now to validate responses when QTYPE=*. As + described in Section 6.2.2 of RFC1034, a proper response to QTYPE=* + may include a subset of the RRsets at a given name -- it is not + necessary to include all RRsets at the QNAME in the response. + + When validating a response to QTYPE=*, validate all received RRsets + that match QNAME and QCLASS. If any of those RRsets fail validation, + treat the answer as Bogus. If there are no RRsets matching QNAME and + QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as + clarified in this document). To be clear, a validator must not + insist on receiving all records at the QNAME in response to QTYPE=*. + +3. Interoperability Concerns + +3.1 Unknown DS Message Digest Algorithms + + Section 5.2 of RFC4035 includes rules for how to handle delegations + to zones that are signed with entirely unsupported algorithms, as + indicated by the algorithms shown in those zone's DS RRsets. It does + not explicitly address how to handle DS records that use unsupported + message digest algorithms. In brief, DS records using unknown or + unsupported message digest algorithms MUST be treated the same way as + DS records referring to DNSKEY RRs of unknown or unsupported + algorithms. + + The existing text says: + + If the validator does not support any of the algorithms listed + in an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + + + +Weiler Expires November 24, 2005 [Page 5] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + To paraphrase the above, when determining the security status of a + zone, a validator discards (for this purpose only) any DS records + listing unknown or unsupported algorithms. If none are left, the + zone is treated as if it were unsigned. + + Modified to consider DS message digest algorithms, a validator also + discards any DS records using unknown or unsupported message digest + algorithms. + +3.2 Private Algorithms + + As discussed above, section 5.2 of RFC4035 requires that validators + make decisions about the security status of zones based on the public + key algorithms shown in the DS records for those zones. In the case + of private algorithms, as described in RFC4034 Appendix A.1.1, the + eight-bit algorithm field in the DS RR is not conclusive about what + algorithm(s) is actually in use. + + If no private algorithms appear in the DS set or if any supported + algorithm appears in the DS set, no special processing will be + needed. In the remaining cases, the security status of the zone + depends on whether or not the resolver supports any of the private + algorithms in use (provided that these DS records use supported hash + functions, as discussed in Section 3.1). In these cases, the + resolver MUST retrieve the corresponding DNSKEY for each private + algorithm DS record and examine the public key field to determine the + algorithm in use. The security-aware resolver MUST ensure that the + hash of the DNSKEY RR's owner name and RDATA matches the digest in + the DS RR. If they do not match, and no other DS establishes that + the zone is secure, the referral should be considered BAD data, as + discussed in RFC4035. + + This clarification facilitates the broader use of private algorithms, + as suggested by [5]. + +3.3 Caution About Local Policy and Multiple RRSIGs + + When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3 + suggests that "the local resolver security policy determines whether + the resolver also has to test these RRSIG RRs and how to resolve + conflicts if these RRSIG RRs lead to differing results." In most + cases, a resolver would be well advised to accept any valid RRSIG as + sufficient. If the first RRSIG tested fails validation, a resolver + would be well advised to try others, giving a successful validation + result if any can be validated and giving a failure only if all + RRSIGs fail validation. + + If a resolver adopts a more restrictive policy, there's a danger that + + + +Weiler Expires November 24, 2005 [Page 6] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + properly-signed data might unnecessarily fail validation, perhaps + because of cache timing issues. Furthermore, certain zone management + techniques, like the Double Signature Zone-signing Key Rollover + method described in section 4.2.1.2 of [6] might not work reliably. + +3.4 Key Tag Calculation + + RFC4034 Appendix B.1 incorrectly defines the Key Tag field + calculation for algorithm 1. It correctly says that the Key Tag is + the most significant 16 of the least significant 24 bits of the + public key modulus. However, RFC4034 then goes on to incorrectly say + that this is 4th to last and 3rd to last octets of the public key + modulus. It is, in fact, the 3rd to last and 2nd to last octets. + +4. Minor Corrections and Clarifications + +4.1 Finding Zone Cuts + + Appendix C.8 of RFC4035 discusses sending DS queries to the servers + for a parent zone. To do that, a resolver may first need to apply + special rules to discover what those servers are. + + As explained in Section 3.1.4.1 of RFC4035, security-aware name + servers need to apply special processing rules to handle the DS RR, + and in some situations the resolver may also need to apply special + rules to locate the name servers for the parent zone if the resolver + does not already have the parent's NS RRset. Section 4.2 of RFC4035 + specifies a mechanism for doing that. + +4.2 Clarifications on DNSKEY Usage + + Questions of the form "can I use a different DNSKEY for signing the + X" have occasionally arisen. + + The short answer is "yes, absolutely". You can even use a different + DNSKEY for each RRset in a zone, subject only to practical limits on + the size of the DNSKEY RRset. However, be aware that there is no way + to tell resolvers what a particularly DNSKEY is supposed to be used + for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to + authenticate any RRset in the zone. For example, if a weaker or less + trusted DNSKEY is being used to authenticate NSEC RRsets or all + dynamically updated records, that same DNSKEY can also be used to + sign any other RRsets from the zone. + + Furthermore, note that the SEP bit setting has no effect on how a + DNSKEY may be used -- the validation process is specifically + prohibited from using that bit by RFC4034 section 2.1.2. It possible + to use a DNSKEY without the SEP bit set as the sole secure entry + + + +Weiler Expires November 24, 2005 [Page 7] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + point to the zone, yet use a DNSKEY with the SEP bit set to sign all + RRsets in the zone (other than the DNSKEY RRset). It's also possible + to use a single DNSKEY, with or without the SEP bit set, to sign the + entire zone, including the DNSKEY RRset itself. + +4.3 Errors in Examples + + The text in RFC4035 Section C.1 refers to the examples in B.1 as + "x.w.example.com" while B.1 uses "x.w.example". This is painfully + obvious in the second paragraph where it states that the RRSIG labels + field value of 3 indicates that the answer was not the result of + wildcard expansion. This is true for "x.w.example" but not for + "x.w.example.com", which of course has a label count of 4 + (antithetically, a label count of 3 would imply the answer was the + result of a wildcard expansion). + + The first paragraph of RFC4035 Section C.6 also has a minor error: + the reference to "a.z.w.w.example" should instead be "a.z.w.example", + as in the previous line. + +5. IANA Considerations + + This document specifies no IANA Actions. + +6. Security Considerations + + This document does not make fundamental changes to the DNSSEC + protocol, as it was generally understood when DNSSECbis was + published. It does, however, address some ambiguities and omissions + in those documents that, if not recognized and addressed in + implementations, could lead to security failures. In particular, the + validation algorithm clarifications in Section 2 are critical for + preserving the security properties DNSSEC offers. Furthermore, + failure to address some of the interoperability concerns in Section 3 + could limit the ability to later change or expand DNSSEC, including + by adding new algorithms. + +7. References + +7.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. + + + +Weiler Expires November 24, 2005 [Page 8] + +Internet-Draft DNSSECbis Implementation Notes May 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. + +7.2 Informative References + + [5] Blacka, D., "DNSSEC Experiments", + draft-blacka-dnssec-experiments-00 (work in progress), + December 2004. + + [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-04 (work in + progress), May 2005. + + +Author's Address + + Samuel Weiler + SPARTA, Inc + 7075 Samuel Morse Drive + Columbia, Maryland 21046 + US + + Email: weiler@tislabs.com + +Appendix A. Acknowledgments + + The editor is extremely grateful to those who, in addition to finding + errors and omissions in the DNSSECbis document set, have provided + text suitable for inclusion in this document. + + The lack of specificity about handling private algorithms, as + described in Section 3.2, and the lack of specificity in handling ANY + queries, as described in Section 2.3, were discovered by David + Blacka. + + The error in algorithm 1 key tag calculation, as described in + Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake + contributed text for Section 3.4. + + The bug relating to delegation NSEC RR's in Section 2.1 was found by + Roy Badami. Roy Arends found the related problem with DNAME. + + The errors in the RFC4035 examples were found by Roy Arends, who also + contributed text for Section 4.3 of this document. + + + +Weiler Expires November 24, 2005 [Page 9] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + + The editor would like to thank Olafur Gudmundsson and Scott Rose for + their substantive comments on the text of this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weiler Expires November 24, 2005 [Page 10] + +Internet-Draft DNSSECbis Implementation Notes May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Weiler Expires November 24, 2005 [Page 11] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt new file mode 100644 index 0000000..c8db709 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt @@ -0,0 +1,840 @@ + + + +DNSEXT D. Blacka +Internet-Draft VeriSign, Inc. +Intended status: Standards Track April 7, 2006 +Expires: October 9, 2006 + + + DNSSEC Experiments + draft-ietf-dnsext-dnssec-experiments-03 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on October 9, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 1] + +Internet-Draft DNSSEC Experiments April 2006 + + +Abstract + + This document describes a methodology for deploying alternate, non- + backwards-compatible, DNSSEC methodologies in an experimental fashion + without disrupting the deployment of standard DNSSEC. + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . 13 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 2] + +Internet-Draft DNSSEC Experiments April 2006 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [5]) and the DNS security extensions ([2], [3], and [4] is assumed. + + The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 3] + +Internet-Draft DNSSEC Experiments April 2006 + + +2. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC and to try these + changes on real zones in the public DNS. This creates a problem when + the change to DNSSEC would make all or part of the zone using those + changes appear bogus (bad) or otherwise broken to existing security- + aware resolvers. + + This document describes a standard methodology for setting up DNSSEC + experiments. This methodology addresses the issue of co-existence + with standard DNSSEC and DNS by using unknown algorithm identifiers + to hide the experimental DNSSEC protocol modifications from standard + security-aware resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 4] + +Internet-Draft DNSSEC Experiments April 2006 + + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and servers that do implement the + DNSSEC standard. + + Non-Backwards-Compatible: describes experiments that would cause a + standard security-aware resolver to (incorrectly) determine that + all or part of a zone is bogus, or to otherwise not interoperate + with standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly may be used + if desired. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 5] + +Internet-Draft DNSSEC Experiments April 2006 + + +4. Method + + The core of the methodology is the use of strictly unknown algorithm + identifiers when signing the experimental zone, and more importantly, + having only unknown algorithm identifiers in the DS records for the + delegation to the zone at the parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithm identifiers. From [4], Section 5.2: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + And further: + + If the resolver does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver will not be able to + verify the authentication path to the child zone. In this case, + the resolver SHOULD treat the child zone as if it were unsigned. + + While this behavior isn't strictly mandatory (as marked by MUST), it + is likely that a validator would implement this behavior, or, more to + the point, it would handle this situation in a safe way (see below + (Section 6).) + + Because we are talking about experiments, it is RECOMMENDED that + private algorithm numbers be used (see [3], appendix A.1.1. Note + that secure handling of private algorithms requires special handing + by the validator logic. See [6] for further details.) Normally, + instead of actually inventing new signing algorithms, the recommended + path is to create alternate algorithm identifiers that are aliases + for the existing, known algorithms. While, strictly speaking, it is + only necessary to create an alternate identifier for the mandatory + algorithms, it is suggested that all optional defined algorithms be + aliased as well. + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + + + +Blacka Expires October 9, 2006 [Page 6] + +Internet-Draft DNSSEC Experiments April 2006 + + + will suffice. + + Using this method, resolvers (or, more specifically, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of security-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiment's algorithm identifiers and + experimental semantics), and servers and resolvers that are unaware + of the experiment. + + This method also precludes any zone from being both in an experiment + and in a classic DNSSEC island of security. That is, a zone is + either in an experiment and only experimentally validatable, or it is + not. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 7] + +Internet-Draft DNSSEC Experiments April 2006 + + +5. Defining an Experiment + + The DNSSEC experiment MUST define the particular set of (previously + unknown) algorithm identifiers that identify the experiment, and + define what each unknown algorithm identifier means. Typically, + unless the experiment is actually experimenting with a new DNSSEC + algorithm, this will be a mapping of private algorithm identifiers to + existing, known algorithms. + + Normally the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + OID private algorithm space instead (using algorithm number 254), or + MAY choose non-private algorithm numbers, although this would require + an IANA allocation. + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and declare + that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC + algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an + alias of DNSSEC algorithm 5 (RSASHA1). + + Resolvers MUST only recognize the experiment's semantics when present + in a zone signed by one or more of these algorithm identifiers. This + is necessary to isolate the semantics of one experiment from any + others that the resolver might understand. + + In general, resolvers involved in the experiment are expected to + understand both standard DNSSEC and the defined experimental DNSSEC + protocol, although this isn't required. + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 8] + +Internet-Draft DNSSEC Experiments April 2006 + + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. Under some circumstances, it may be that the experiment will not + be sufficiently masked by this technique and may cause resolution + problem for resolvers not aware of the experiment. For instance, + the resolver may look at a non-validatable response and conclude + that the response is bogus, either due to local policy or + implementation details. This is not expected to be a common + case, however. + + 2. It will not be possible for security-aware resolvers unaware of + the experiment to build a chain of trust through an experimental + zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 9] + +Internet-Draft DNSSEC Experiments April 2006 + + +7. Use in Non-Experiments + + This general methodology MAY be used for non-backwards compatible + DNSSEC protocol changes that start out as or become standards. In + this case: + + o The protocol change SHOULD use public IANA allocated algorithm + identifiers instead of private algorithm identifiers. This will + help identify the protocol change as a standard, rather than an + experiment. + + o Resolvers MAY recognize the protocol change in zones not signed + (or not solely signed) using the new algorithm identifiers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 10] + +Internet-Draft DNSSEC Experiments April 2006 + + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 11] + +Internet-Draft DNSSEC Experiments April 2006 + + +9. IANA Considerations + + This document has no IANA actions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 12] + +Internet-Draft DNSSEC Experiments April 2006 + + +10. References + +10.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + +10.2. Informative References + + [5] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [6] Austein, R. and S. Weiler, "Clarifications and Implementation + Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02 + (work in progress), January 2006. + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 13] + +Internet-Draft DNSSEC Experiments April 2006 + + +Author's Address + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blacka Expires October 9, 2006 [Page 14] + +Internet-Draft DNSSEC Experiments April 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Blacka Expires October 9, 2006 [Page 15] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt new file mode 100644 index 0000000..7503c66 --- /dev/null +++ b/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/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt new file mode 100644 index 0000000..17e28e8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt @@ -0,0 +1,896 @@ + + + +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: January 19, 2006 M. Kosters + D. Blacka + Verisign, Inc. + July 18, 2005 + + + DNSSEC Opt-In + draft-ietf-dnsext-dnssec-opt-in-07 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 19, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC + 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are + cryptographically secured. Maintaining this cryptography is not + practical or necessary. This document describes an experimental + "Opt-In" model that allows administrators to omit this cryptography + and manage the cost of adopting DNSSEC with large zones. + + + +Arends, et al. Expires January 19, 2006 [Page 1] + +Internet-Draft DNSSEC Opt-In July 2005 + + +Table of Contents + + 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4 + 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5 + 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5 + 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6 + 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6 + 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7 + 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7 + 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7 + 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8 + 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8 + 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 11.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 2] + +Internet-Draft DNSSEC Opt-In July 2005 + + +1. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([3], [4], and [5], referred to in this + document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 + [10]) is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + unsigned name: refers to a DNS name that does not (at least) have a + NSEC record. + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + delegation: refers to a NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described in this document. + + 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 [7]. + +2. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NSEC record chain may be extremely high relative to + the gain of cryptographically authenticating existence of unsecured + zones. + + This document describes an experimental method of eliminating the + + + +Arends, et al. Expires January 19, 2006 [Page 3] + +Internet-Draft DNSSEC Opt-In July 2005 + + + superfluous cryptography present in secure delegations to unsigned + zones. Using "Opt-In", a zone administrator can choose to remove + insecure delegations from the NSEC chain. This is accomplished by + extending the semantics of the NSEC record by using a redundant bit + in the type map. + +3. Experimental Status + + This document describes an EXPERIMENTAL extension to DNSSEC. It + interoperates with non-experimental DNSSEC using the technique + described in [6]. This experiment is identified with the following + private algorithms (using algorithm 253): + + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + and + "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + RSASHA1. + + Servers wishing to sign and serve zones that utilize Opt-In MUST sign + the zone with only one or more of these private algorithms. This + requires the signing tools and servers to support private algorithms, + as well as Opt-In. + + Resolvers wishing to validate Opt-In zones MUST only do so when the + zone is only signed using one or more of these private algorithms. + + The remainder of this document assumes that the servers and resolvers + involved are aware of and are involved in this experiment. + +4. Protocol Additions + + In DNSSEC, delegation NS RRsets are not signed, but are instead + accompanied by a NSEC RRset of the same name and (possibly) 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. Opt-In expands this definition by allowing insecure + delegations to exist within an otherwise signed zone without the + corresponding NSEC record at the delegation's owner name. These + insecure delegations are proven insecure by using a covering NSEC + record. + + Since this represents a change of the interpretation of NSEC records, + resolvers must be able to distinguish between RFC standard DNSSEC + NSEC records and Opt-In NSEC records. This is accomplished by + "tagging" the NSEC records that cover (or potentially cover) insecure + delegation nodes. This tag is indicated by the absence of the NSEC + bit in the type map. Since the NSEC bit in the type map merely + indicates the existence of the record itself, this bit is redundant + + + +Arends, et al. Expires January 19, 2006 [Page 4] + +Internet-Draft DNSSEC Opt-In July 2005 + + + and safe for use as a tag. + + An Opt-In tagged NSEC record does not assert the (non)existence of + the delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning records in the NSEC chain. + However, Opt-In tagged NSEC records do assert the (non)existence of + other RRsets. + + An Opt-In NSEC record MAY have the same 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 NSEC record does assert + the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC + records and standard DNSSEC NSEC records. If a NSEC record is not + Opt-In, there MUST NOT be any insecure delegations (or any other + records) between it and the RRsets indicated by the 'next domain + name' in the NSEC RDATA. If it is Opt-In, there MUST only be + insecure delegations between it and the next node indicated by the + 'next domain name' in the NSEC RDATA. + + In summary, + + o An Opt-In NSEC type is identified by a zero-valued (or not- + specified) NSEC bit in the type bit map of the NSEC record. + o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in + the type bit map of the NSEC record. + + and, + + o An Opt-In NSEC record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + o An Opt-In NSEC record does assert the (non)existence of RRsets + with the same owner name. + +4.1 Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +4.1.1 Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NSEC record. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. Servers also SHOULD reject AXFR or IXFR + + + +Arends, et al. Expires January 19, 2006 [Page 5] + +Internet-Draft DNSSEC Opt-In July 2005 + + + responses that violate this restriction. + +4.1.2 Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NSEC RRset in the Authority section. + + In standard DNSSEC, NSEC records already must be returned along with + the insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NSEC record will have a + different owner name from the delegation RRset. This may require + implementations to search for the covering NSEC RRset. + +4.1.3 Wildcards and Opt-In + + Standard DNSSEC describes the practice of returning NSEC records to + prove the non-existence of an applicable wildcard in non-existent + name responses. This NSEC record can be described as a "negative + wildcard proof". The use of Opt-In NSEC records changes the + necessity for this practice. For non-existent name responses when + the query name (qname) is covered by an Opt-In tagged NSEC record, + servers MAY choose to omit the wildcard proof record, and clients + MUST NOT treat the absence of this NSEC record as a validation error. + + The intent of the standard DNSSEC negative wildcard proof requirement + is to prevent malicious users from undetectably removing valid + wildcard responses. In order for this cryptographic proof to work, + the resolver must be able to prove: + + 1. The exact qname does not exist. This is done by the "normal" + NSEC record. + 2. No applicable wildcard exists. This is done by returning a NSEC + record proving that the wildcard does not exist (this is the + negative wildcard proof). + + However, if the NSEC record covering the exact qname is an Opt-In + NSEC record, the resolver will not be able to prove the first part of + this equation, as the qname might exist as an insecure delegation. + Thus, since the total proof cannot be completed, the negative + wildcard proof NSEC record is not useful. + + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and + therefore cannot prove that a wildcard expansion is valid. + + The presence of an Opt-In tagged NSEC record does not change the + practice of returning a NSEC along with a wildcard expansion. Even + + + +Arends, et al. Expires January 19, 2006 [Page 6] + +Internet-Draft DNSSEC Opt-In July 2005 + + + though the Opt-In NSEC will not be able to prove that the wildcard + expansion is valid, it will prove that the wildcard expansion is not + masking any signed records. + +4.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NSEC chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NSEC records. Servers SHOULD return responses + to update requests with RCODE=REFUSED. + +4.2 Client Considerations + + Opt-In imposes some new requirements on security-aware resolvers + (caching or otherwise). + +4.2.1 Delegations Only + + As stated in the "Server Considerations" section above, this + specification restricts the namespace covered by Opt-In tagged NSEC + records to insecure delegations only. Thus, resolvers MUST reject as + invalid any records that fall within an Opt-In NSEC record's span + that are not NS records or corresponding glue records. + +4.2.2 Validation Process Changes + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + Resolvers MUST be able to use Opt-In tagged NSEC records to + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In standard DNSSEC, the security status is proven by the existence + or absence of a DS RRset at the same name as the delegation. The + existence of the DS RRset indicates that the referred-to zone is + signed. The absence of the DS RRset is proven using a verified + NSEC record of the same name that does not have the DS bit set in + the type map. This NSEC record MAY also be tagged as Opt-In. + o Using Opt-In, the security status is proven by the existence of a + DS record (for signed) or the presence of a verified Opt-In tagged + NSEC record that covers the delegation name. That is, the NSEC + record does not have the NSEC bit set in the type map, and the + delegation name falls between the NSEC's owner and "next" name. + + + + +Arends, et al. Expires January 19, 2006 [Page 7] + +Internet-Draft DNSSEC Opt-In July 2005 + + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the referred-to subzone is signed + or unsigned. + + When receiving either an Opt-In insecure delegation response or a + non-existent name response where that name is covered by an Opt-In + tagged NSEC record, the resolver MUST NOT require proof (in the form + of a NSEC record) that a wildcard did not exist. + +4.2.3 NSEC Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NSEC record when returning referrals that need them. This + requirement differs from standard DNSSEC in that the covering NSEC + will not have the same owner name as the delegation. Some + implementations may have to use new methods for finding these NSEC + records. + +4.2.4 Use of the AD bit + + The AD bit, as defined by [2] and [5], MUST NOT be set when: + + o sending a Name Error (RCODE=3) response where the covering NSEC is + tagged as Opt-In. + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NSEC record's owner name equals the delegation + name. + + This rule is based on what the Opt-In NSEC record actually proves: + for names that exist between the Opt-In NSEC record's owner and + "next" names, the Opt-In NSEC record cannot prove the non-existence + or existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + +5. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for NSEC records for + insecure delegations. This, in a zone with a large number of + delegations to unsigned subzones, can lead to substantial space + savings (both in memory and on disk). Additionally, Opt-In allows + for the addition or removal of insecure delegations without modifying + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., TLDs) can avoid the substantial overhead of + + + +Arends, et al. Expires January 19, 2006 [Page 8] + +Internet-Draft DNSSEC Opt-In July 2005 + + + modifying and resigning the affected NSEC records. + +6. Example + + Consider the zone EXAMPLE, shown below. This is a zone where all of + the NSEC records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. RRSIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. RRSIG NS ... + EXAMPLE. DNSKEY ... + EXAMPLE. RRSIG DNSKEY ... + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. ( + SOA NS RRSIG DNSKEY ) + EXAMPLE. RRSIG NSEC ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. RRSIG A ... + FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG + FIRST-SECURE.EXAMPLE. RRSIG NSEC ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG + NOT-SECURE-2.EXAMPLE RRSIG NSEC ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. RRSIG DS ... + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + In this example, a query for a signed RRset (e.g., "FIRST- + SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- + SECURE.EXAMPLE A") will result in a standard DNSSEC response. + + A query for a nonexistent RRset will result in a response that + differs from standard DNSSEC by: the NSEC record will be tagged as + Opt-In, there may be no NSEC record proving the non-existence of a + + + +Arends, et al. Expires January 19, 2006 [Page 9] + +Internet-Draft DNSSEC Opt-In July 2005 + + + matching wildcard record, and the AD bit will not be set. + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NSEC record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NSEC record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NSEC record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS + RRSIG DNSKEY NSEC ) + + However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND- + SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure + delegations in the range they define. (NOT-SECURE.EXAMPLE. and + UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is + part of the NSEC chain and also covered by an Opt-In tagged NSEC + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be + removed from the zone without modifying and resigning the prior NSEC + record. Delegations with names that fall between NOT-SECURE- + 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without + resigning any NSEC records. + +7. Transition Issues + + Opt-In is not backwards compatible with standard DNSSEC and is + considered experimental. Standard DNSSEC compliant implementations + would not recognize Opt-In tagged NSEC records as different from + + + +Arends, et al. Expires January 19, 2006 [Page 10] + +Internet-Draft DNSSEC Opt-In July 2005 + + + standard NSEC records. Because of this, standard DNSSEC + implementations, if they were to validate Opt-In style responses, + would reject all Opt-In insecure delegations within a zone as + invalid. However, by only signing with private algorithms, standard + DNSSEC implementations will treat Opt-In responses as unsigned. + + It should be noted that all elements in the resolution path between + (and including) the validator and the authoritative name server must + be aware of the Opt-In experiment and implement the Opt-In semantics + for successful validation to be possible. In particular, this + includes any caching middleboxes between the validator and + authoritative name server. + +8. Security Considerations + + Opt-In 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: + + o 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 [12] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + o 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 have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NSEC 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: + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 11] + +Internet-Draft DNSSEC Opt-In July 2005 + + + 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 + EXAMPLE. RRSIG NSEC ... + + Additional Section: + + + The resolver would have no choice but to believe 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 Opt-In, and + MAY choose to not support Opt-In at all. + +9. IANA Considerations + + None. + +10. Acknowledgments + + The contributions, suggestions and remarks of the following persons + (in alphabetic order) to this draft are acknowledged: + + Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf + Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning, + Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian + Wellington. + +11. References + + + + +Arends, et al. Expires January 19, 2006 [Page 12] + +Internet-Draft DNSSEC Opt-In July 2005 + + +11.1 Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [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] Blacka, D., "DNSSEC Experiments", + draft-ietf-dnsext-dnssec-experiments-01 (work in progress), + July 2005. + +11.2 Informative References + + [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [9] Eastlake, D., "Secure Domain Name System Dynamic Update", + RFC 2137, April 1997. + + [10] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 13] + +Internet-Draft DNSSEC Opt-In July 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + Email: roy.arends@telin.nl + + + Mark Kosters + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: markk@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + Verisign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + Email: davidb@verisign.com + URI: http://www.verisignlabs.com + +Appendix A. Implementing Opt-In using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NSEC records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + + + +Arends, et al. Expires January 19, 2006 [Page 14] + +Internet-Draft DNSSEC Opt-In July 2005 + + + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + V_A is the secure view as described above. + V_B is the insecure view as described above. + R_A is a response generated from V_A, following RFC 2535bis. + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + R_C is the response generated by combining R_A with R_B, as + described below. + A query is DNSSEC-aware if it either has the DO bit [11] turned + on, or is for a DNSSEC-specific record type. + + + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + 2. Generate R_A. + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + 4. Generate R_B and combine it with R_A to form R_C: + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + 5. Return R_C. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires January 19, 2006 [Page 15] + +Internet-Draft DNSSEC Opt-In July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires January 19, 2006 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-06.txt new file mode 100644 index 0000000..1dc9070 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-06.txt @@ -0,0 +1,504 @@ + + + +DNS Extensions working group J. Jansen +Internet-Draft NLnet Labs +Intended status: Standards Track October 23, 2008 +Expires: April 26, 2009 + + + Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records + for DNSSEC + draft-ietf-dnsext-dnssec-rsasha256-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 April 26, 2009. + +Abstract + + This document describes how to produce RSA/SHA-256 and RSA/SHA-512 + DNSKEY and RRSIG resource records for use in the Domain Name System + Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 1] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 + 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 + 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3 + 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 + 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 + 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 5 + 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 + 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Implementation Considerations . . . . . . . . . . . . . . . . . 5 + 5.1. Support for SHA-2 signatures . . . . . . . . . . . . . . . 5 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource + Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 + Intellectual Property and Copyright Statements . . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 2] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical distributed + database for Internet Naming. The DNS has been extended to use + cryptographic keys and digital signatures for the verification of the + authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 + [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security + Extensions, called DNSSEC. + + RFC 4034 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 algorithms RSA/SHA-256 and RSA/ + SHA-512, and specifies how to store DNSKEY data and how to produce + RRSIG resource records with these hash algorithms. + + Familiarity with DNSSEC, RSA and the SHA-2 [FIPS.180-2.2002] family + of algorithms is assumed in this document. + + To refer to both SHA-256 and SHA-512, this document will use the name + SHA-2. This is done to improve readability. When a part of text is + specific for either SHA-256 or SHA-512, their specific names are + used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be + grouped using the name RSA/SHA-2. + + +2. DNSKEY Resource Records + + The format of the DNSKEY RR can be found in RFC 4034 [RFC4034], RFC + 3110 [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures. + +2.1. 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 {TBA1}. + + For use with NSEC3 [RFC5155], the algorithm number for RSA/SHA-256 + will be {TBA2}. The use of a different algorithm number to + differentiate between the use of NSEC and NSEC3 is in keeping with + the approach adopted in RFC5155. + + For interoperability, as in RFC 3110 [RFC3110], the key size of RSA/ + SHA-256 keys MUST NOT be less than 512 bits, and MUST NOT be more + than 4096 bits. + +2.2. RSA/SHA-512 DNSKEY Resource Records + + RSA public keys for use with RSA/SHA-512 are stored in DNSKEY + resource records (RRs) with the algorithm number {TBA3}. + + + +Jansen Expires April 26, 2009 [Page 3] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + For use with NSEC3, the algorithm number for RSA/SHA-512 will be + {TBA4}. The use of a different algorithm number to differentiate + between the use of NSEC and NSEC3 is in keeping with the approach + adopted in RFC5155. + + The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits, and + MUST NOT be more than 4096 bits. + + +3. RRSIG Resource Records + + The value of the signature field in the RRSIG RR follows the RSASSA- + PKCS1-v1_5 signature scheme, and is calculated as follows. The + values for the RDATA fields that precede the signature data are + specified in RFC 4034 [RFC4034]. + + hash = SHA-XXX(data) + + Here XXX is either 256 or 512, depending on the algorithm used, as + specified in FIPS PUB 180-2 [FIPS.180-2.2002], and "data" is the wire + format data of the resource record set that is signed, as specified + in RFC 4034 [RFC4034]. + + signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) + + Here "|" 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 exact number of times so that + the total length of the concatenated term in parentheses equals the + length of the modulus of the signer's public key ("n"). + + The "prefix" is intended to make the use of standard cryptographic + libraries easier. These specifications are taken directly from the + specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 section 8.2 + [RFC3447], and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 section 9.2 + [RFC3447]. The prefixes for the different algorithms are specified + below. + +3.1. RSA/SHA-256 RRSIG Resource Records + + RSA/SHA-256 signatures are stored in the DNS using RRSIG resource + records (RRs) with algorithm number {TBA1} for use with NSEC, or + {TBA2} for use with NSEC3. + + The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as + specified in PKCS #1 v2.1 [RFC3447]: + + + + +Jansen Expires April 26, 2009 [Page 4] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 + +3.2. RSA/SHA-512 RRSIG Resource Records + + RSA/SHA-512 signatures are stored in the DNS using RRSIG resource + records (RRs) with algorithm number {TBA3} for use with NSEC, or + {TBA4} for use with NSEC3. + + The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as + specified in PKCS #1 v2.1 [RFC3447]: + + hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 + + +4. Deployment Considerations + +4.1. Key Sizes + + Apart from the restrictions specified in section 2, this document + will not specify what size of keys to use. That is an operational + issue and depends largely on the environment and intended use. A + good starting point for more information would be NIST SP 800-57 + [NIST800-57]. + +4.2. Signature Sizes + + In this family of signing algorithms, the size of signatures is + related to the size of the key, and not the hashing algorithm used in + the signing process. Therefore, RRSIG resource records produced with + RSA/SHA256 or RSA/SHA512 will have the same size as those produced + with RSA/SHA1, if the keys have the same length. + + +5. Implementation Considerations + +5.1. Support for SHA-2 signatures + + DNSSEC aware implementations SHOULD be able to support RRSIG resource + records with the RSA/SHA-2 algorithms. + + +6. IANA Considerations + + IANA has assigned DNS Security Algorithm Numbers {TBA1} for RSA/ + SHA-256 with NSEC, {TBA2} for RSA/SHA-256 with NSEC3, {TBA3} for RSA/ + SHA-512 with NSEC, and {TBA4} for RSA/SHA-512 with NSEC3. + + The algorithm list from RFC 4034 Appendix A.1 [RFC4034] is extended + + + +Jansen Expires April 26, 2009 [Page 5] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + with the following entries: + + Zone + Value Algorithm [Mnemonic] Signing References + {TBA1} RSA/SHA-256 RSASHA256 y {this memo} + {TBA2} RSA/SHA-256-NSEC3 RSASHA256NSEC3 y {this memo} + {TBA3} RSA/SHA-512 RSASHA512 y {this memo} + {TBA4} RSA/SHA-512-NSEC3 RSASHA512NSEC3 y {this memo} + + + +7. Security Considerations + +7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records + + Users of DNSSEC are encouraged to deploy SHA-2 as soon as software + implementations allow for it. SHA-2 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-2 is the better choice for use in + DNSSEC records. + + SHA-2 is considered sufficiently strong for the immediate future, but + predictions about future development in cryptography and + cryptanalysis are beyond the scope of this document. + + The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one + used for RSA/SHA-1 signatures. This should ease implementation of + the new hashing algorithms in DNSSEC software. + +7.2. Signature Type Downgrade Attacks + + Since each RRSet MUST be signed with each algorithm present in the + DNSKEY RRSet at the zone apex (see [RFC4035] Section 2.2), a + malicious party cannot filter out the RSA/SHA-2 RRSIG, and force the + validator to use the RSA/SHA-1 signature if both are present in the + zone. This should provide resilience against algorithm downgrade + attacks, if the validator supports RSA/SHA-2. + + +8. Acknowledgments + + This document is a minor extension to RFC 4034 [RFC4034]. Also, we + try to follow the documents RFC 3110 [RFC3110] and RFC 4509 [RFC4509] + for consistency. The authors of and contributors to these documents + are gratefully acknowledged for their hard work. + + + + +Jansen Expires April 26, 2009 [Page 6] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + + The following people provided additional feedback and text: Jaap + Akkerhuis, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, + Alfred Hoenes, Paul Hoffman, Peter Koch, Michael St. Johns, Scott + Rose and Wouter Wijngaards. + + +9. References + +9.1. Normative References + + [FIPS.180-2.2002] + National Institute of Standards and Technology, "Secure + Hash Standard", FIPS PUB 180-2, August 2002. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [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. + +9.2. Informative References + + [NIST800-57] + Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, + "Recommendations for Key Management", NIST SP 800-57, + March 2007. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + + + + + +Jansen Expires April 26, 2009 [Page 7] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +Author's Address + + Jelte Jansen + NLnet Labs + Kruislaan 419 + Amsterdam 1098VA + NL + + Email: jelte@NLnetLabs.nl + URI: http://www.nlnetlabs.nl/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 8] + +Internet-Draft DNSSEC RSA/SHA-2 October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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. + + + + + + + + + + + +Jansen Expires April 26, 2009 [Page 9] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt new file mode 100644 index 0000000..dd8cbf0 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt @@ -0,0 +1,839 @@ + +DNS Extensions Working Group R. Arends +Internet-Draft Telematica Instituut +Expires: August 25, 2005 P. Koch + DENIC eG + J. Schlyter + NIC-SE + February 21, 2005 + + + Evaluating DNSSEC Transition Mechanisms + draft-ietf-dnsext-dnssec-trans-02.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 25, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document collects and summarizes different proposals for + alternative and additional strategies for authenticated denial in DNS + responses, evaluates these proposals and gives a recommendation for a + + + +Arends, et al. Expires August 25, 2005 [Page 1] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + way forward. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 + 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 + 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5 + 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 + 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6 + 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 + 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 + 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 + 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9 + 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10 + 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10 + 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11 + 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11 + 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13 + 5.2 Informative References . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 + Intellectual Property and Copyright Statements . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 2] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +1. Introduction + + This report shall document the process of dealing with the NSEC + walking problem late in the Last Call for + [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol, + I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion + that took place in the DNSEXT WG during the first half of June 2004 + as well as some additional ideas that came up subsequently. + + This is an edited excerpt of the chairs' mail to the WG: + The working group consents on not including NSEC-alt in the + DNSSEC-bis documents. The working group considers to take up + "prevention of zone enumeration" as a work item. + There may be multiple mechanisms to allow for co-existence with + DNSSEC-bis. The chairs allow the working group a little over a + week (up to June 12, 2004) to come to consensus on a possible + modification to the document to enable gentle rollover. If that + consensus cannot be reached the DNSSEC-bis documents will go out + as-is. + + To ease the process of getting consensus, a summary of the proposed + solutions and analysis of the pros and cons were written during the + weekend. + + This summary includes: + + An inventory of the proposed mechanisms to make a transition to + future work on authenticated denial of existence. + List the known Pros and Cons, possibly provide new arguments, and + possible security considerations of these mechanisms. + Provide a recommendation on a way forward that is least disruptive + to the DNSSEC-bis specifications as they stand and keep an open + path to other methods for authenticated denial of existence. + + The descriptions of the proposals in this document are coarse and do + not cover every detail necessary for implementation. In any case, + documentation and further study is needed before implementaion and/or + deployment, including those which seem to be solely operational in + nature. + +2. Transition Mechanisms + + In the light of recent discussions and past proposals, we have found + several ways to allow for transition to future expansion of + authenticated denial. We tried to illuminate the paths and pitfalls + in these ways forward. Some proposals lead to a versioning of + DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other + proposals are 'clean' but may cause delay, while again others may be + + + +Arends, et al. Expires August 25, 2005 [Page 3] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + plain hacks. + + Some paths do not introduce versioning, and might require the current + DNSSEC-bis documents to be fully updated to allow for extensions to + authenticated denial mechanisms. Other paths introduce versioning + and do not (or minimally) require DNSSEC-bis documents to be updated, + allowing DNSSEC-bis to be deployed, while future versions can be + drafted independent from or partially depending on DNSSEC-bis. + +2.1 Mechanisms With Need of Updating DNSSEC-bis + + Mechanisms in this category demand updates to the DNSSEC-bis document + set. + +2.1.1 Dynamic NSEC Synthesis + + This proposal assumes that NSEC RRs and the authenticating RRSIG will + be generated dynamically to just cover the (non existent) query name. + The owner name is (the) one preceding the name queried for, the Next + Owner Name Field has the value of the Query Name Field + 1 (first + successor in canonical ordering). A separate key (the normal ZSK or + a separate ZSK per authoritative server) would be used for RRSIGs on + NSEC RRs. This is a defense against enumeration, though it has the + presumption of online signing. + +2.1.1.1 Coexistence and Migration + + There is no change in interpretation other then that the next owner + name might or might not exist. + +2.1.1.2 Limitations + + This introduces an unbalanced cost between query and response + generation due to dynamic generation of signatures. + +2.1.1.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents might need to be updated to indicate + that the next owner name might not be an existing name in the zone. + This is not a real change to the spec since implementers have been + warned not to synthesize with previously cached NSEC records. A + specific bit to identify the dynamic signature generating key might + be useful as well, to prevent it from being used to fake positive + data. + +2.1.1.4 Cons + + Unbalanced cost is a ground for DDoS. Though this protects against + + + +Arends, et al. Expires August 25, 2005 [Page 4] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + enumeration, it is not really a path for versioning. + +2.1.1.5 Pros + + Hardly any amendments to DNSSEC-bis. + +2.1.2 Add Versioning/Subtyping to Current NSEC + + This proposal introduces versioning for the NSEC RR type (a.k.a. + subtyping) by adding a (one octet) version field to the NSEC RDATA. + Version number 0 is assigned to the current (DNSSEC-bis) meaning, + making this an 'Must Be Zero' (MBZ) for the to be published docset. + +2.1.2.1 Coexistence and Migration + + Since the versioning is done inside the NSEC RR, different versions + may coexist. However, depending on future methods, that may or may + not be useful inside a single zone. Resolvers cannot ask for + specific NSEC versions but may be able to indicate version support by + means of a to be defined EDNS option bit. + +2.1.2.2 Limitations + + There are no technical limitations, though it will cause delay to + allow testing of the (currently unknown) new NSEC interpretation. + + Since the versioning and signaling is done inside the NSEC RR, future + methods will likely be restricted to a single RR type authenticated + denial (as opposed to e.g. NSEC-alt, which currently proposes three + RR types). + +2.1.2.3 Amendments to DNSSEC-bis + + Full Update of the current DNSSEC-bis documents to provide for new + fields in NSEC, while specifying behavior in case of unknown field + values. + +2.1.2.4 Cons + + Though this is a clean and clear path without versioning DNSSEC, it + takes some time to design, gain consensus, update the current + dnssec-bis document, test and implement a new authenticated denial + record. + +2.1.2.5 Pros + + Does not introduce an iteration to DNSSEC while providing a clear and + clean migration strategy. + + + +Arends, et al. Expires August 25, 2005 [Page 5] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.3 Type Bit Map NSEC Indicator + + Bits in the type-bit-map are reused or allocated to signify the + interpretation of NSEC. + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + the RDATA or introduce an alternative denial mechanism, invoked by + the specific type-bit-map-bits. + +2.1.3.1 Coexistence and migration + + Old and new NSEC meaning could coexist, depending how the signaling + would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR + types are available as well as those covering meta/query types or + types to be specifically allocated. + +2.1.3.2 Limitations + + This mechanism uses an NSEC field that was not designed for that + purpose. Similar methods were discussed during the Opt-In discussion + and the Silly-State discussion. + +2.1.3.3 Amendments to DNSSEC-bis + + The specific type-bit-map-bits must be allocated and they need to be + specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) + interpretation. Also, behaviour of the resolver and validator must + be documented in case unknown values are encountered for the MBZ + field. Currently the protocol document specifies that the validator + MUST ignore the setting of the NSEC and the RRSIG bits, while other + bits are only used for the specific purpose of the type-bit-map field + +2.1.3.4 Cons + + The type-bit-map was not designed for this purpose. It is a + straightforward hack. Text in protocol section 5.4 was put in + specially to defend against this usage. + +2.1.3.5 Pros + + No change needed to the on-the-wire protocol as specified in the + current docset. + +2.1.4 New Apex Type + + This introduces a new Apex type (parallel to the zone's SOA) + indicating the DNSSEC version (or authenticated denial) used in or + + + +Arends, et al. Expires August 25, 2005 [Page 6] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + for this zone. + +2.1.4.1 Coexistence and Migration + + Depending on the design of this new RR type multiple denial + mechanisms may coexist in a zone. Old validators will not understand + and thus ignore the new type, so interpretation of the new NSEC + scheme may fail, negative responses may appear 'bogus'. + +2.1.4.2 Limitations + + A record of this kind is likely to carry additional + feature/versioning indications unrelated to the current question of + authenticated denial. + +2.1.4.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the absence of this type indicates dnssec-bis, and that the (mere) + presence of this type indicated unknown versions. + +2.1.4.4 Cons + + The only other 'zone' or 'apex' record is the SOA record. Though + this proposal is not new, it is yet unknown how it might fulfill + authenticated denial extensions. This new RR type would only provide + for a generalized signaling mechanism, not the new authenticated + denial scheme. Since it is likely to be general in nature, due to + this generality consensus is not to be reached soon. + +2.1.4.5 Pros + + This approach would allow for a lot of other per zone information to + be transported or signaled to both (slave) servers and resolvers. + +2.1.5 NSEC White Lies + + This proposal disables one part of NSEC (the pointer part) by means + of a special target (root, apex, owner, ...), leaving intact only the + ability to authenticate denial of existence of RR sets, not denial of + existence of domain names (NXDOMAIN). It may be necessary to have + one working NSEC to prove the absence of a wildcard. + +2.1.5.1 Coexistence and Migration + + The NSEC target can be specified per RR, so standard NSEC and 'white + lie' NSEC can coexist in a zone. There is no need for migration + because no versioning is introduced or intended. + + + +Arends, et al. Expires August 25, 2005 [Page 7] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.5.2 Limitations + + This proposal breaks the protocol and is applicable to certain types + of zones only (no wildcard, no deep names, delegation only). Most of + the burden is put on the resolver side and operational consequences + are yet to be studied. + +2.1.5.3 Amendments to DNSSEC-bis + + The current DNSSEC-bis documents need to be updated to indicate that + the NXDOMAIN responses may be insecure. + +2.1.5.4 Cons + + Strictly speaking this breaks the protocol and doesn't fully fulfill + the requirements for authenticated denial of existence. Security + implications need to be carefully documented: search path problems + (forged denial of existence may lead to wrong expansion of non-FQDNs + [RFC1535]) and replay attacks to deny existence of records. + +2.1.5.5 Pros + + Hardly any amendments to DNSSEC-bis. Operational "trick" that is + available anyway. + +2.1.6 NSEC Optional via DNSSKEY Flag + + A new DNSKEY may be defined to declare NSEC optional per zone. + +2.1.6.1 Coexistence and Migration + + Current resolvers/validators will not understand the Flag bit and + will have to treat negative responses as bogus. Otherwise, no + migration path is needed since NSEC is simply turned off. + +2.1.6.2 Limitations + + NSEC can only be made completely optional at the cost of being unable + to prove unsecure delegations (absence of a DS RR [RFC3658]). A next + to this approach would just disable authenticated denial for + non-existence of nodes. + +2.1.6.3 Amendments to DNSSEC-bis + + New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to + be specified in the light of absence of authenticated denial. + + + + + +Arends, et al. Expires August 25, 2005 [Page 8] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.6.4 Cons + + Doesn't fully meet requirements. Operational consequences to be + studied. + +2.1.6.5 Pros + + Official version of the "trick" presented in (8). Operational + problems can be addressed during future work on validators. + +2.1.7 New Answer Pseudo RR Type + + A new pseudo RR type may be defined that will be dynamically created + (and signed) by the responding authoritative server. The RR in the + response will cover the QNAME, QCLASS and QTYPE and will authenticate + both denial of existence of name (NXDOMAIN) or RRset. + +2.1.7.1 Coexistence and Migration + + Current resolvers/validators will not understand the pseudo RR and + will thus not be able to process negative responses so testified. A + signaling or solicitation method would have to be specified. + +2.1.7.2 Limitations + + This method can only be used with online keys and online signing + capacity. + +2.1.7.3 Amendments to DNSSEC-bis + + Signaling method needs to be defined. + +2.1.7.4 Cons + + Keys have to be held and processed online with all security + implications. An additional flag for those keys identifying them as + online or negative answer only keys should be considered. + +2.1.7.5 Pros + + Expands DNSSEC authentication to the RCODE. + +2.1.8 SIG(0) Based Authenticated Denial + + +2.1.8.1 Coexistence and Migration + + + + + +Arends, et al. Expires August 25, 2005 [Page 9] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.1.8.2 Limitations + + +2.1.8.3 Amendments to DNSSEC-bis + + +2.1.8.4 Cons + + +2.1.8.5 Pros + + +2.2 Mechanisms Without Need of Updating DNSSEC-bis + +2.2.1 Partial Type-code and Signal Rollover + + Carefully crafted type code/signal rollover to define a new + authenticated denial space that extends/replaces DNSSEC-bis + authenticated denial space. This particular path is illuminated by + Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com> + posted to <namedroppers@ops.ietf.org> 2004-06-02. + +2.2.1.1 Coexistence and Migration + + To protect the current resolver for future versions, a new DNSSEC-OK + bit must be allocated to make clear it does or does not understand + the future version. Also, a new DS type needs to be allocated to + allow differentiation between a current signed delegation and a + 'future' signed delegation. Also, current NSEC needs to be rolled + into a new authenticated denial type. + +2.2.1.2 Limitations + + None. + +2.2.1.3 Amendments to DNSSEC-bis + + None. + +2.2.1.4 Cons + + It is cumbersome to carefully craft an TCR that 'just fits'. The + DNSSEC-bis protocol has many 'borderline' cases that needs special + consideration. It might be easier to do a full TCR, since a few of + the types and signals need upgrading anyway. + + + + + + +Arends, et al. Expires August 25, 2005 [Page 10] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +2.2.1.5 Pros + + Graceful adoption of future versions of NSEC, while there are no + amendments to DNSSEC-bis. + +2.2.2 A Complete Type-code and Signal Rollover + + A new DNSSEC space is defined which can exist independent of current + DNSSEC-bis space. + + This proposal assumes that all current DNSSEC type-codes + (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any + future versions of DNSSEC. Any future version of DNSSEC has its own + types to allow for keys, signatures, authenticated denial, etcetera. + +2.2.2.1 Coexistence and Migration + + Both spaces can co-exist. They can be made completely orthogonal. + +2.2.2.2 Limitations + + None. + +2.2.2.3 Amendments to DNSSEC-bis + + None. + +2.2.2.4 Cons + + With this path we abandon the current DNSSEC-bis. Though it is easy + to role specific well-known and well-tested parts into the re-write, + once deployment has started this path is very expensive for + implementers, registries, registrars and registrants as well as + resolvers/users. A TCR is not to be expected to occur frequently, so + while a next generation authenticated denial may be enabled by a TCR, + it is likely that that TCR will only be agreed upon if it serves a + whole basket of changes or additions. A quick introduction of + NSEC-ng should not be expected from this path. + +2.2.2.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. It is + always there as last resort. + +2.2.3 Unknown Algorithm in RRSIG + + This proposal assumes that future extensions make use of the existing + NSEC RDATA syntax, while it may need to change the interpretation of + + + +Arends, et al. Expires August 25, 2005 [Page 11] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + the RDATA or introduce an alternative denial mechanism, invoked by + the specific unknown signing algorithm. The different interpretation + would be signaled by use of different signature algorithms in the + RRSIG records covering the NSEC RRs. + + When an entire zone is signed with a single unknown algorithm, it + will cause implementations that follow current dnssec-bis documents + to treat individual RRsets as unsigned. + +2.2.3.1 Coexistence and migration + + Old and new NSEC RDATA interpretation or known and unknown Signatures + can NOT coexist in a zone since signatures cover complete (NSEC) + RRSets. + +2.2.3.2 Limitations + + Validating resolvers agnostic of new interpretation will treat the + NSEC RRset as "not signed". This affects wildcard and non-existence + proof, as well as proof for (un)secured delegations. Also, all + positive signatures (RRSIGs on RRSets other than DS, NSEC) appear + insecure/bogus to an old validator. + + The algorithm version space is split for each future version of + DNSSEC. Violation of the 'modular components' concept. We use the + 'validator' to protect the 'resolver' from unknown interpretations. + +2.2.3.3 Amendments to DNSSEC-bis + + None. + +2.2.3.4 Cons + + The algorithm field was not designed for this purpose. This is a + straightforward hack. + +2.2.3.5 Pros + + No amendments/changes to current DNSSEC-bis docset needed. + +3. Recommendation + + The authors recommend that the working group commits to and starts + work on a partial TCR, allowing graceful transition towards a future + version of NSEC. Meanwhile, to accomodate the need for an + immediately, temporary, solution against zone-traversal, we recommend + On-Demand NSEC synthesis. + + + + +Arends, et al. Expires August 25, 2005 [Page 12] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + This approach does not require any mandatory changes to DNSSEC-bis, + does not violate the protocol and fulfills the requirements. As a + side effect, it moves the cost of implementation and deployment to + the users (zone owners) of this mechanism. + +4. Acknowledgements + + The authors would like to thank Sam Weiler and Mark Andrews for their + input and constructive comments. + +5. References + +5.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Massey, D., Larson, M. and S. + Rose, "DNS Security Introduction and Requirements", + Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., "Protocol Modifications for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-protocol-09, + October 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., "Resource Records for the DNS Security + Extensions", + Internet-Draft draft-ietf-dnsext-dnssec-records-11, + October 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + +5.2 Informative References + + [RFC1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, October + 1993. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + + + +Arends, et al. Expires August 25, 2005 [Page 13] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + + RFC 2535, March 1999. + + [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, + June 1999. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + Enschede 7523 XC + The Netherlands + + Phone: +31 53 4850485 + Email: roy.arends@telin.nl + + + Peter Koch + DENIC eG + Wiesenh"uttenplatz 26 + Frankfurt 60329 + Germany + + Phone: +49 69 27235 0 + Email: pk@DENIC.DE + + + Jakob Schlyter + NIC-SE + Box 5774 + Stockholm SE-114 87 + Sweden + + Email: jakob@nic.se + URI: http://www.nic.se/ + + + + + + + + + + + + +Arends, et al. Expires August 25, 2005 [Page 14] + +Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Arends, et al. Expires August 25, 2005 [Page 15] + + diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt new file mode 100644 index 0000000..2460cb6 --- /dev/null +++ b/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/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt new file mode 100644 index 0000000..2cdcdb1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT ECC Keys in the DNS +Expires: January 2006 July 2005 + + + + Elliptic Curve KEYs in the DNS + -------- ----- ---- -- --- --- + <draft-ietf-dnsext-ecc-key-07.txt> + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + This draft is intended to be become a Proposed Standard RFC. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list <namedroppers@ops.ietf.org>. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is specified. + + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC Keys in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Copyright Notice...........................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve Data in Resource Records.................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + Copyright and Disclaimer..................................14 + + Informational References..................................15 + Normative Refrences.......................................15 + + Author's Addresses........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC Keys in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 4033, 4034, + 4035]. + + This document describes how to store elliptic curve cryptographic + (ECC) keys and signatures in the DNS so they can be used for a + variety of security purposes. Familiarity with ECC cryptography is + assumed [Menezes]. + + 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. Elliptic Curve Data in Resource Records + + Elliptic curve public keys are stored in the DNS within the RDATA + portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the + structure shown below. + + The research world continues to work on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. So, representations are + defined for every type of finite field, and every type of elliptic + curve. The reader should be aware that there is a unique finite + field with a particular number of elements, but many possible + representations of that field and its elements. If two different + representations of a field are given, they are interconvertible with + a tedious but practical precomputation, followed by a fast + computation for each field element to be converted. It is perfectly + reasonable for an algorithm to work internally with one field + representation, and convert to and from a different external + representation. + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC Keys in the DNS + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC Keys in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC Keys in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of an RR and MUST be + ignored when processing an RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range + [0,P-1]. The coefficients are packed into fixed-width fields, from + higher order to lower order. All coefficients must be present, + including any 0s and also the leading coefficient (which is required + to be 1). The coefficients are right justified into the octet string + of length specified by LF, with the low-order "constant" coefficient + at the right end. As a concession to storage efficiency, the higher + order bits of the leading coefficient may be elided, discarding high- + order 0 octets and reducing LF. The degree is calculated by + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC Keys in the DNS + + + determining the bit position of the left most 1-bit in the F data + (counting the right most bit as position 0), and dividing by + ceiling(log2 P). The division must be exact, with no remainder. In + this format, all of the other degree and field parameters are + omitted. The next parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of + degree D is X^D (which is not irreducible). The next is X^D+1, which + is sometimes irreducible, followed by X^D-1, which isn't. Assuming + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC Keys in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC Keys in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC Keys in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC Keys in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Elliptic Curve SIG Resource Records + + The signature portion of an RR RDATA area when using the EC + algorithm, for example in the RRSIG and SIG [RFC records] RRs is + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two + different messages with the same K. K should be chosen from a + very large space: If an opponent learns a K value for a single + signature, the user's signing key is compromised, and a forger + can sign arbitrary messages. There is no harm in signing the + same message multiple times with the same key or different + keys.) + + R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC Keys in the DNS + + + as an integer, and reduced (mod Q). (R must not be 0. In + this astronomically unlikely event, generate a new random K + and recalculate R.) + + S = ( K^(-1) * (hash + X*R) ) mod Q. + + S must not be 0. In this astronomically unlikely event, generate a + new random K and recalculate R and S. + + If S > Q/2, set S = Q - S. + + The pair (R,S) is the signature. + + Another party verifies the signature as follows: + + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + + hash = SHA-1 ( data ) + + Sinv = S^(-1) mod Q. + + U1 = (hash * Sinv) mod Q. + + U2 = (R * Sinv) mod Q. + + (U1 * G + U2 * Y) is computed on the elliptic curve. + + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + + The signature is valid if V = R. + + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for + hash(data)+Q or hash(data)-Q, if these happen to fall in the range + [0,2^160-1]. It's believed to be computationally infeasible to + find data that hashes to an assigned value, so this is only a + cosmetic blemish. The blemish can be eliminated by using Q > + 2^160, at the cost of having slightly longer signatures, 42 octets + instead of 40. + + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the + obvious thing". In the (mod P) case, E is simply a residue mod P, + and is taken as an integer in the range [0,P-1]. In the GF[2^D] + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC Keys in the DNS + + + case, E is in the D-bit polynomial basis representation, and is + simply taken as an integer in the range [0,(2^D)-1]. For other + fields GF[P^D], it's necessary to do some radix conversion + arithmetic. + + + + 6. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than + RSA and DSA. Creation of a curve is slow, but not done very often. + Key generation is faster than RSA or DSA. + + DNS implementations have been optimized for small transfers, + typically less than 512 octets including DNS overhead. Larger + transfers will perform correctly and and extensions have been + standardized to make larger transfers more efficient [RFC 2671]. + However, it is still advisable at this time to make reasonable + efforts to minimize the size of RR sets stored within the DNS + consistent with adequate security. + + + + 7. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + Some specific key generation considerations are given in the body + of this document. + + + + 8. IANA Considerations + + The key and signature data structures defined herein correspond to + the value 4 in the Algorithm number field of the IANA registry + + Assignment of meaning to the remaining ECC data flag bits or to + values of ECC fields outside the ranges for which meaning in + defined in this document requires an IETF consensus as defined in + [RFC 2434]. + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Copyright and Disclaimer + + Copyright (C) The Internet Society 2005. This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on + an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, + EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT + THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR + ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A + PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Informational References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", + August 1999. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June + 2005. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic + Curves", 1986, Springer Graduate Texts in mathematics #106. + + + + Normative Refrences + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security Extensions", RFC + 4034, March 2005. + + + + + + + +R. Schroeppel, et al [Page 15] + + +INTERNET-DRAFT ECC Keys in the DNS + + + Author's Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, UT 84653 USA + + Telephone: +1-505-844-9079(w) + Email: rschroe@sandia.gov + + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1 508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + Expiration and File Name + + This draft expires in January 2006. + + Its file name is draft-ietf-dnsext-ecc-key-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt new file mode 100644 index 0000000..87bce00 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt @@ -0,0 +1,17 @@ + +This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted +from the Internet-Drafts directory. An Internet-Draft expires 185 days from +the date that it is posted unless it is replaced by an updated version, or the +Secretariat has been notified that the document is under official review by the +IESG or has been passed to the RFC Editor for review and/or publication as an +RFC. This Internet-Draft was not published as an RFC. + +Internet-Drafts are not archival documents, and copies of Internet-Drafts that have +been deleted from the directory are not available. The Secretariat does not have +any information regarding the future plans of the author(s) or working group, if +applicable, with respect to this deleted Internet-Draft. For more information, or +to request a copy of the document, please contact the author(s) directly. + +Draft Author(s): +Remco van Mook <remco@virtu.nl>, +Bert Hubert <bert.hubert@netherlabs.nl> diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt new file mode 100644 index 0000000..160afc3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-interop3597-02.txt @@ -0,0 +1,334 @@ +DNS Extensions Working Group J. Schlyter +Internet-Draft May 19, 2005 +Expires: November 20, 2005 + + + RFC 3597 Interoperability Report + draft-ietf-dnsext-interop3597-02.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 November 20, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 1] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3 + 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3 + 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4 + 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4 + 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 + A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 + Intellectual Property and Copyright Statements . . . . . . . . 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 2] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +1. Introduction + + This memo documents the result from the RFC 3597 (Handling of Unknown + DNS Resource Record Types) interoperability testing. The test was + performed during June and July 2004 by request of the IETF DNS + Extensions Working Group. + +2. Implementations + + The following is a list, in alphabetic order, of implementations + tested for compliance with RFC 3597: + + DNSJava 1.6.4 + ISC BIND 8.4.5 + ISC BIND 9.3.0 + NSD 2.1.1 + Net::DNS 0.47 patchlevel 1 + Nominum ANS 2.2.1.0.d + + These implementations covers the following functions (number of + implementations tested for each function in paranthesis): + + Authoritative Name Servers (4) + Full Recursive Resolver (2) + Stub Resolver (4) + DNSSEC Zone Signers (2) + + All listed implementations are genetically different. + +3. Tests + + The following tests was been performed to validate compliance with + RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression") + and 5 ("Text Representation"). + +3.1 Authoritative Primary Name Server + + The test zone data (Appendix A) was loaded into the name server + implementation and the server was queried for the loaded information. + +3.2 Authoritative Secondary Name Server + + The test zone data (Appendix A) was transferred using AXFR from + another name server implementation and the server was queried for the + transferred information. + + + + + + +Schlyter Expires November 20, 2005 [Page 3] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +3.3 Full Recursive Resolver + + A recursive resolver was queried for resource records from a domain + with the test zone data (Appendix A). + +3.4 Stub Resolver + + A stub resolver was used to query resource records from a domain with + the test zone data (Appendix A). + +3.5 DNSSEC Signer + + A DNSSEC signer was used to sign a zone with test zone data + (Appendix A). + +4. Problems found + + Two implementations had problems with text presentation of zero + length RDATA. + + One implementation had problems with text presentation of RR type + code and classes >= 4096. + + Bug reports were filed for problems found. + +5. Summary + + Unknown type codes works in the tested authoritative servers, + recursive resolvers and stub clients. + + No changes are needed to advance RFC 3597 to draft standard. + +6. Normative References + + [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + +Author's Address + + Jakob Schlyter + + Email: jakob@rfc.se + + + + + + + + +Schlyter Expires November 20, 2005 [Page 4] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Appendix A. Test zone data + + ; A-record encoded as TYPE1 + a TYPE1 \# 4 7f000001 + a TYPE1 192.0.2.1 + a A \# 4 7f000002 + + ; draft-ietf-secsh-dns-05.txt + sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e + + ; bogus test record (from RFC 3597) + type731 TYPE731 \# 6 abcd ( + ef 01 23 45 ) + + ; zero length RDATA (from RFC 3597) + type62347 TYPE62347 \# 0 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 20, 2005 [Page 5] + +Internet-Draft RFC 3597 Interoperability Report May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Schlyter Expires November 20, 2005 [Page 6] + + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt new file mode 100644 index 0000000..6bffb70 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt @@ -0,0 +1,560 @@ + +DNS Extensions O. Kolkman +Internet-Draft RIPE NCC +Expires: June 17, 2004 J. Schlyter + + E. Lewis + ARIN + December 18, 2003 + + + DNSKEY RR Secure Entry Point Flag + draft-ietf-dnsext-keyrr-key-signing-flag-12 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 17, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + With the Delegation Signer (DS) resource record the concept of a + public key acting as a secure entry point has been introduced. During + exchanges of public keys with the parent there is a need to + differentiate secure entry point keys from other public keys in the + DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is + defined to indicate that DNSKEY is to be used as a secure entry + point. The flag bit is intended to assist in operational procedures + to correctly generate DS resource records, or to indicate what + DNSKEYs are intended for static configuration. The flag bit is not to + + + +Kolkman, et al. Expires June 17, 2004 [Page 1] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + be used in the DNS verification protocol. This document updates RFC + 2535 and RFC 3445. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4 + 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Internationalization Considerations . . . . . . . . . . . . . . 6 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 2] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + +1. Introduction + + "All keys are equal but some keys are more equal than others" [6] + + With the definition of the Delegation Signer Resource Record (DS RR) + [5] it has become important to differentiate between the keys in the + DNSKEY RR set that are (to be) pointed to by parental DS RRs and the + other keys in the DNSKEY RR set. We refer to these public keys as + Secure Entry Point (SEP) keys. A SEP key either used to generate a + DS RR or is distributed to resolvers that use the key as the root of + a trusted subtree[3]. + + In early deployment tests, the use of two (kinds of) key pairs for + each zone has been prevalent. For one kind of key pair the private + key is used to sign just the zone's DNSKEY resource record (RR) set. + Its public key is intended to be referenced by a DS RR at the parent + or configured statically in a resolver. The private key of the other + kind of key pair is used to sign the rest of the zone's data sets. + The former key pair is called a key-signing key (KSK) and the latter + is called a zone-signing key (ZSK). In practice there have been + usually one of each kind of key pair, but there will be multiples of + each at times. + + It should be noted that division of keys pairs into KSK's and ZSK's + is not mandatory in any definition of DNSSEC, not even with the + introduction of the DS RR. But, in testing, this distinction has + been helpful when designing key roll over (key super-cession) + schemes. Given that the distinction has proven helpful, the labels + KSK and ZSK have begun to stick. + + There is a need to differentiate the public keys for the key pairs + that are used for key signing from keys that are not used key signing + (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to + be sent for generating DS RRs, which DNSKEYs are to be distributed to + resolvers, and which keys are fed to the signer application at the + appropriate time. + + In other words, the SEP bit provides an in-band method to communicate + a DNSKEY RR's intended use to third parties. As an example we present + 3 use cases in which the bit is useful: + + The parent is a registry, the parent and the child use secured DNS + queries and responses, with a preexisting trust-relation, or plain + DNS over a secured channel to exchange the child's DNSKEY RR + sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset + the SEP bit can be used to isolate the DNSKEYs for which a DS RR + needs to be created. + + + + +Kolkman, et al. Expires June 17, 2004 [Page 3] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + An administrator has configured a DNSKEY as root for a trusted + subtree into security aware resolver. Using a special purpose tool + that queries for the KEY RRs from that domain's apex, the + administrator will be able to notice the roll over of the trusted + anchor by a change of the subset of KEY RRs with the DS flag set. + + A signer might use the SEP bit on the public key to determine + which private key to use to exclusively sign the DNSKEY RRset and + which private key to use to sign the other RRsets in the zone. + + As demonstrated in the above examples it is important to be able to + differentiate the SEP keys from the other keys in a DNSKEY RR set in + the flow between signer and (parental) key-collector and in the flow + between the signer and the resolver configuration. The SEP flag is to + be of no interest to the flow between the verifier and the + authoritative data store. + + The reason for the term "SEP" is a result of the observation that the + distinction between KSK and ZSK key pairs is made by the signer, a + key pair could be used as both a KSK and a ZSK at the same time. To + be clear, the term SEP was coined to lessen the confusion caused by + the overlap. ( Once this label was applied, it had the side effect of + removing the temptation to have both a KSK flag bit and a ZSK flag + bit.) + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119 [1]. + +2. The Secure Entry Point (SEP) Flag + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | flags |S| protocol | algorithm | + | |E| | | + | |P| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DNSKEY RR Format + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 4] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + This document assigns the 15'th bit in the flags field as the secure + entry point (SEP) bit. If the the bit is set to 1 the key is + intended to be used as secure entry point key. One SHOULD NOT assign + special meaning to the key if the bit is set to 0. Operators can + recognize the secure entry point key by the even or odd-ness of the + decimal representation of the flag field. + +3. DNSSEC Protocol Changes + + The bit MUST NOT be used during the resolving and verification + process. The SEP flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the SEP flag does not change the DNS resolution protocol or the + resolution process. + +4. Operational Guidelines + + The SEP bit is set by the key-pair-generator and MAY be used by the + zone signer to decide whether the public part of the key pair is to + be prepared for input to a DS RR generation function. The SEP bit is + recommended to be set (to 1) whenever the public key of the key pair + will be distributed to the parent zone to build the authentication + chain or if the public key is to be distributed for static + configuration in verifiers. + + When a key pair is created, the operator needs to indicate whether + the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within + the data that is used to compute the 'key tag field' in the SIG RR, + changing the SEP bit will change the identity of the key within DNS. + In other words, once a key is used to generate signatures, the + setting of the SEP bit is to remain constant. If not, a verifier will + not be able to find the relevant KEY RR. + + When signing a zone, it is intended that the key(s) with the SEP bit + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a SEP bit set will sign the + DNSKEY RR set, such keys might be pending retirement or not yet in + use. + + When verifying a RR set, the SEP bit is not intended to play a role. + How the key is used by the verifier is not intended to be a + consideration at key creation time. + + Although the SEP flag provides a hint on which public key is to be + used as trusted root, administrators can choose to ignore the fact + that a DNSKEY has its SEP bit set or not when configuring a trusted + root for their resolvers. + + + +Kolkman, et al. Expires June 17, 2004 [Page 5] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + Using the SEP flag a key roll over can be automated. The parent can + use an existing trust relation to verify DNSKEY RR sets in which a + new DNSKEY RR with the SEP flag appears. + +5. Security Considerations + + As stated in Section 3 the flag is not to be used in the resolution + protocol or to determine the security status of a key. The flag is to + be used for administrative purposes only. + + No trust in a key should be inferred from this flag - trust MUST be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag might be used for automating public key exchanges, we + think the following consideration is in place. + + Automated mechanisms for roll over of the DS RR might be vulnerable + to a class of replay attacks. This might happen after a public key + exchange where a DNSKEY RR set, containing two DNSKEY RRs with the + SEP flag set, is sent to the parent. The parent verifies the DNSKEY + RR set with the existing trust relation and creates the new DS RR + from the DNSKEY RR that the current DS RR is not pointing to. This + key exchange might be replayed. Parents are encouraged to implement a + replay defense. A simple defense can be based on a registry of keys + that have been used to generate DS RRs during the most recent roll + over. These same considerations apply to entities that configure keys + in resolvers. + +6. IANA Considerations + + The flag bits in the DNSKEY RR are assigned by IETF consensus and + registered in the DNSKEY Flags registry (created by [4]). This + document assigns the 15th bit in the DNSKEY RR as the Secure Entry + Point (SEP) bit. + +7. Internationalization Considerations + + Although SEP is a popular acronym in many different languages, there + are no internationalization considerations. + +8. Acknowledgments + + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among + others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, + Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler + have contributed ideas and provided feedback. + + + + +Kolkman, et al. Expires June 17, 2004 [Page 6] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI in August 2002. + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work + in progress), October 2003. + +Informative References + + [5] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), June + 2003. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story", ISBN 0151002177 (50th anniversary edition), April 1996. + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + Karl Gustavsgatan 15 + Goteborg SE-411 25 + Sweden + + EMail: jakob@schlyter.se + + + + +Kolkman, et al. Expires June 17, 2004 [Page 7] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + Edward P. Lewis + ARIN + 3635 Concorde Parkway Suite 200 + Chantilly, VA 20151 + US + + Phone: +1 703 227 9854 + EMail: edlewis@arin.net + URI: http://www.arin.net/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 8] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Kolkman, et al. Expires June 17, 2004 [Page 9] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 10] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-46.txt b/doc/draft/draft-ietf-dnsext-mdns-46.txt new file mode 100644 index 0000000..63d0b23 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-46.txt @@ -0,0 +1,1801 @@ + + + + + + +DNSEXT Working Group Bernard Aboba +INTERNET-DRAFT Dave Thaler +Category: Standards Track Levon Esibov +<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation +16 April 2006 + + Linklocal Multicast Name Resolution (LLMNR) + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on October 15, 2006. + +Copyright Notice + + Copyright (C) The Internet Society 2006. + +Abstract + + The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable + name resolution in scenarios in which conventional DNS name + resolution is not possible. LLMNR supports all current and future + DNS formats, types and classes, while operating on a separate port + from DNS, and with a distinct resolver cache. Since LLMNR only + operates on the local link, it cannot be considered a substitute for + DNS. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 1] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Table of Contents + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 4 + 1.2 Terminology ..................................... 4 +2. Name Resolution Using LLMNR ........................... 4 + 2.1 LLMNR Packet Format ............................. 5 + 2.2 Sender Behavior ................................. 8 + 2.3 Responder Behavior .............................. 8 + 2.4 Unicast Queries and Responses ................... 11 + 2.5 Off-link Detection .............................. 11 + 2.6 Responder Responsibilities ...................... 12 + 2.7 Retransmission and Jitter ....................... 13 + 2.8 DNS TTL ......................................... 14 + 2.9 Use of the Authority and Additional Sections .... 14 +3. Usage model ........................................... 15 + 3.1 LLMNR Configuration ............................. 16 +4. Conflict Resolution ................................... 18 + 4.1 Uniqueness Verification ......................... 18 + 4.2 Conflict Detection and Defense .................. 19 + 4.3 Considerations for Multiple Interfaces .......... 20 + 4.4 API issues ...................................... 22 +5. Security Considerations ............................... 22 + 5.1 Denial of Service ............................... 22 + 5.2 Spoofing ...............,........................ 23 + 5.3 Authentication .................................. 24 + 5.4 Cache and Port Separation ....................... 24 +6. IANA considerations ................................... 25 +7. Constants ............................................. 25 +8. References ............................................ 26 + 8.1 Normative References ............................ 26 + 8.2 Informative References .......................... 26 +Acknowledgments .............................................. 28 +Authors' Addresses ........................................... 28 +Intellectual Property Statement .............................. 29 +Disclaimer of Validity ....................................... 29 +Copyright Statement .......................................... 29 + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 2] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +1. Introduction + + This document discusses Link Local Multicast Name Resolution (LLMNR), + which is based on the DNS packet format and supports all current and + future DNS formats, types and classes. LLMNR operates on a separate + port from the Domain Name System (DNS), with a distinct resolver + cache. + + Since LLMNR only operates on the local link, it cannot be considered + a substitute for DNS. Link-scope multicast addresses are used to + prevent propagation of LLMNR traffic across routers, potentially + flooding the network. LLMNR queries can also be sent to a unicast + address, as described in Section 2.4. + + Propagation of LLMNR packets on the local link is considered + sufficient to enable name resolution in small networks. In such + networks, if a network has a gateway, then typically the network is + able to provide DNS server configuration. Configuration issues are + discussed in Section 3.1. + + In the future, it may be desirable to consider use of multicast name + resolution with multicast scopes beyond the link-scope. This could + occur if LLMNR deployment is successful, the need arises for + multicast name resolution beyond the link-scope, or multicast routing + becomes ubiquitous. For example, expanded support for multicast name + resolution might be required for mobile ad-hoc networks. + + Once we have experience in LLMNR deployment in terms of + administrative issues, usability and impact on the network, it will + be possible to reevaluate which multicast scopes are appropriate for + use with multicast name resolution. IPv4 administratively scoped + multicast usage is specified in "Administratively Scoped IP + Multicast" [RFC2365]. + + Service discovery in general, as well as discovery of DNS servers + using LLMNR in particular, is outside of the scope of this document, + as is name resolution over non-multicast capable media. + +1.1. Requirements + + In this document, several words are used to signify the requirements + of the specification. The key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 3] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +1.2. Terminology + + This document assumes familiarity with DNS terminology defined in + [RFC1035]. Other terminology used in this document includes: + +Routable Address + An address other than a Link-Local address. This includes globally + routable addresses, as well as private addresses. + +Reachable + An LLMNR responder considers one of its addresses reachable over a + link if it will respond to an ARP or Neighbor Discovery query for + that address received on that link. + +Responder + A host that listens to LLMNR queries, and responds to those for + which it is authoritative. + +Sender + A host that sends an LLMNR query. + +UNIQUE + There are some scenarios when multiple responders may respond to + the same query. There are other scenarios when only one responder + may respond to a query. Names for which only a single responder is + anticipated are referred to as UNIQUE. Name uniqueness is + configured on the responder, and therefore uniqueness verification + is the responder's responsibility. + +2. Name Resolution Using LLMNR + + LLMNR queries are sent to and received on port 5355. The IPv4 link- + scope multicast address a given responder listens to, and to which a + sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast + address a given responder listens to, and to which a sender sends all + queries, is FF02:0:0:0:0:0:1:3. + + Typically a host is configured as both an LLMNR sender and a + responder. A host MAY be configured as a sender, but not a + responder. However, a host configured as a responder MUST act as a + sender, if only to verify the uniqueness of names as described in + Section 4. This document does not specify how names are chosen or + configured. This may occur via any mechanism, including DHCPv4 + [RFC2131] or DHCPv6 [RFC3315]. + + A typical sequence of events for LLMNR usage is as follows: + + [a] An LLMNR sender sends an LLMNR query to the link-scope + + + +Aboba, Thaler & Esibov Standards Track [Page 4] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + multicast address(es), unless a unicast query is indicated, + as specified in Section 2.4. + + [b] A responder responds to this query only if it is authoritative + for the name in the query. A responder responds to a + multicast query by sending a unicast UDP response to the sender. + Unicast queries are responded to as indicated in Section 2.4. + + [c] Upon reception of the response, the sender processes it. + + The sections that follow provide further details on sender and + responder behavior. + +2.1. LLMNR Packet Format + + LLMNR is based on the DNS packet format defined in [RFC1035] Section + 4 for both queries and responses. LLMNR implementations SHOULD send + UDP queries and responses only as large as are known to be + permissible without causing fragmentation. When in doubt a maximum + packet size of 512 octets SHOULD be used. LLMNR implementations MUST + accept UDP queries and responses as large as the smaller of the link + MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 + octets for the header, VLAN tag and CRC). + +2.1.1. LLMNR Header Format + + LLMNR queries and responses utilize the DNS header format defined in + [RFC1035] with exceptions noted below: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + + + + +Aboba, Thaler & Esibov Standards Track [Page 5] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +ID A 16 bit identifier assigned by the program that generates any kind + of query. This identifier is copied from the query to the response + and can be used by the sender to match responses to outstanding + queries. The ID field in a query SHOULD be set to a pseudo-random + value. For advice on generation of pseudo-random values, please + consult [RFC1750]. + +QR Query/Response. A one bit field, which if set indicates that the + message is an LLMNR response; if clear then the message is an LLMNR + query. + +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. + LLMNR senders and responders MUST support standard queries (opcode + value of zero). LLMNR queries with unsupported OPCODE values MUST + be silently discarded by responders. + +C Conflict. When set within a request, the 'C'onflict bit indicates + that a sender has received multiple LLMNR responses to this query. + In an LLMNR response, if the name is considered UNIQUE, then the + 'C' bit is clear, otherwise it is set. LLMNR senders do not + retransmit queries with the 'C' bit set. Responders MUST NOT + respond to LLMNR queries with the 'C' bit set, but may start the + uniqueness verification process, as described in Section 4.2. + +TC TrunCation - specifies that this message was truncated due to + length greater than that permitted on the transmission channel. + The TC bit MUST NOT be set in an LLMNR query and if set is ignored + by an LLMNR responder. If the TC bit is set in an LLMNR response, + then the sender SHOULD resend the LLMNR query over TCP using the + unicast address of the responder as the destination address. If + the sender receives a response to the TCP query, then it SHOULD + discard the UDP response with the TC bit set. See [RFC2181] and + Section 2.4 of this specification for further discussion of the TC + bit. + +T Tentative. The 'T'entative bit is set in a response if the + responder is authoritative for the name, but has not yet verified + the uniqueness of the name. A responder MUST ignore the 'T' bit in + a query, if set. A response with the 'T' bit set is silently + discarded by the sender, except if it is a uniqueness query, in + which case a conflict has been detected and a responder MUST + resolve the conflict as described in Section 4.1. + + + + +Aboba, Thaler & Esibov Standards Track [Page 6] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Z Reserved for future use. Implementations of this specification + MUST set these bits to zero in both queries and responses. If + these bits are set in a LLMNR query or response, implementations of + this specification MUST ignore them. Since reserved bits could + conceivably be used for different purposes than in DNS, + implementors are advised not to enable processing of these bits in + an LLMNR implementation starting from a DNS code base. + +RCODE + Response code -- this 4 bit field is set as part of LLMNR + responses. In an LLMNR query, the sender MUST set RCODE to zero; + the responder ignores the RCODE and assumes it to be zero. The + response to a multicast LLMNR query MUST have RCODE set to zero. A + sender MUST silently discard an LLMNR response with a non-zero + RCODE sent in response to a multicast query. + + If an LLMNR responder is authoritative for the name in a multicast + query, but an error is encountered, the responder SHOULD send an + LLMNR response with an RCODE of zero, no RRs in the answer section, + and the TC bit set. This will cause the query to be resent using + TCP, and allow the inclusion of a non-zero RCODE in the response to + the TCP query. Responding with the TC bit set is preferable to not + sending a response, since it enables errors to be diagnosed. This + may be required, for example, when an LLMNR query includes a TSIG + RR in the additional section, and the responder encounters a + problem that requires returning a non-zero RCODE. TSIG error + conditions defined in [RFC2845] include a TSIG RR in an + unacceptable position (RCODE=1) or a TSIG RR which does not + validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)). + + Since LLMNR responders only respond to LLMNR queries for names for + which they are authoritative, LLMNR responders MUST NOT respond + with an RCODE of 3; instead, they should not respond at all. + + LLMNR implementations MUST support EDNS0 [RFC2671] and extended + RCODE values. + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the + question section of an LLMNR query. LLMNR responders MUST silently + discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders + MUST silently discard LLMNR responses with QDCOUNT not equal to + one. + +ANCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the answer section. LLMNR responders MUST silently + + + +Aboba, Thaler & Esibov Standards Track [Page 7] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + discard LLMNR queries with ANCOUNT not equal to zero. + +NSCOUNT + An unsigned 16 bit integer specifying the number of name server + resource records in the authority records section. Authority + record section processing is described in Section 2.9. LLMNR + responders MUST silently discard LLMNR queries with NSCOUNT not + equal to zero. + +ARCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the additional records section. Additional record + section processing is described in Section 2.9. + +2.2. Sender Behavior + + A sender MAY send an LLMNR query for any legal resource record type + (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address. + As described in Section 2.4, a sender MAY also send a unicast query. + + The sender MUST anticipate receiving no replies to some LLMNR + queries, in the event that no responders are available within the + link-scope. If no response is received, a resolver treats it as a + response that the name does not exist (RCODE=3 is returned). A + sender can handle duplicate responses by discarding responses with a + source IP address and ID field that duplicate a response already + received. + + When multiple valid LLMNR responses are received with the 'C' bit + set, they SHOULD be concatenated and treated in the same manner that + multiple RRs received from the same DNS server would be. However, + responses with the 'C' bit set SHOULD NOT be concatenated with + responses with the 'C' bit clear; instead, only the responses with + the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are + received along with error response(s), then the error responses are + silently discarded. + + Since the responder may order the RRs in the response so as to + indicate preference, the sender SHOULD preserve ordering in the + response to the querying application. + +2.3. Responder Behavior + + An LLMNR response MUST be sent to the sender via unicast. + + Upon configuring an IP address, responders typically will synthesize + corresponding A, AAAA and PTR RRs so as to be able to respond to + LLMNR queries for these RRs. An SOA RR is synthesized only when a + + + +Aboba, Thaler & Esibov Standards Track [Page 8] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + responder has another RR in addition to the SOA RR; the SOA RR MUST + NOT be the only RR that a responder has. However, in general whether + RRs are manually or automatically created is an implementation + decision. + + For example, a host configured to have computer name "host1" and to + be a member of the "example.com" domain, and with IPv4 address + 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be + authoritative for the following records: + + host1. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + host1.example.com. IN A 192.0.2.1 + IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + 1.2.0.192.in-addr.arpa. IN PTR host1. + IN PTR host1.example.com. + + 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2. + ip6.arpa IN PTR host1. (line split for formatting reasons) + IN PTR host1.example.com. + + An LLMNR responder might be further manually configured with the name + of a local mail server with an MX RR included in the "host1." and + "host1.example.com." records. + + In responding to queries: + +[a] Responders MUST listen on UDP port 5355 on the link-scope multicast + address(es) defined in Section 2, and on TCP port 5355 on the + unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. + +[b] Responders MUST direct responses to the port from which the query + was sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses MUST always be sent + from the port to which they were directed. + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups, with the exception of queries with the 'C' bit + set, which do not elicit a response. + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + + + +Aboba, Thaler & Esibov Standards Track [Page 9] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[e] Responders MUST NOT respond using data from the LLMNR or DNS + resolver cache. + +[f] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + +[g] If a responder is authoritative for a name, it MUST respond with + RCODE=0 and an empty answer section, if the type of query does not + match a RR that the responder has. + + As an example, a host configured to respond to LLMNR queries for the + name "foo.example.com." is authoritative for the name + "foo.example.com.". On receiving an LLMNR query for an A RR with the + name "foo.example.com." the host authoritatively responds with A + RR(s) that contain IP address(es) in the RDATA of the resource + record. If the responder has a AAAA RR, but no A RR, and an A RR + query is received, the responder would respond with RCODE=0 and an + empty answer section. + + In conventional DNS terminology a DNS server authoritative for a zone + is authoritative for all the domain names under the zone apex except + for the branches delegated into separate zones. Contrary to + conventional DNS terminology, an LLMNR responder is authoritative + only for the zone apex. + + For example the host "foo.example.com." is not authoritative for the + name "child.foo.example.com." unless the host is configured with + multiple names, including "foo.example.com." and + "child.foo.example.com.". As a result, "foo.example.com." cannot + reply to an LLMNR query for "child.foo.example.com." with RCODE=3 + (authoritative name error). The purpose of limiting the name + authority scope of a responder is to prevent complications that could + be caused by coexistence of two or more hosts with the names + representing child and parent (or grandparent) nodes in the DNS tree, + for example, "foo.example.com." and "child.foo.example.com.". + + Without the restriction on authority an LLMNR query for an A resource + record for the name "child.foo.example.com." would result in two + authoritative responses: RCODE=3 (authoritative name error) received + from "foo.example.com.", and a requested A record - from + "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled + hosts could perform a dynamic update of the parent (or grandparent) + zone with a delegation to a child zone; for example a host + "child.foo.example.com." could send a dynamic update for the NS and + + + +Aboba, Thaler & Esibov Standards Track [Page 10] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + glue A record to "foo.example.com.". However, this approach + significantly complicates implementation of LLMNR and would not be + acceptable for lightweight hosts. + +2.4. Unicast Queries and Responses + + Unicast queries SHOULD be sent when: + + [a] A sender repeats a query after it received a response + with the TC bit set to the previous LLMNR multicast query, or + + [b] The sender queries for a PTR RR of a fully formed IP address + within the "in-addr.arpa" or "ip6.arpa" zones. + + Unicast LLMNR queries MUST be done using TCP and the responses MUST + be sent using the same TCP connection as the query. Senders MUST + support sending TCP queries, and responders MUST support listening + for TCP queries. If the sender of a TCP query receives a response to + that query not using TCP, the response MUST be silently discarded. + + Unicast UDP queries MUST be silently discarded. + + A unicast PTR RR query for an off-link address will not elicit a + response, but instead an ICMP TTL or Hop Limit exceeded message will + be received. An implementation receiving an ICMP message in response + to a TCP connection setup attempt can return immediately, treating + this as a response that no such name exists (RCODE=3 is returned). + An implementation that cannot process ICMP messages MAY send + multicast UDP queries for PTR RRs. Since TCP implementations will + not retransmit prior to RTOmin, a considerable period will elapse + before TCP retransmits multiple times, resulting in a long timeout + for TCP PTR RR queries sent to an off-link destination. + +2.5. "Off link" Detection + + A sender MUST select a source address for LLMNR queries that is + assigned on the interface on which the query is sent. The + destination address of an LLMNR query MUST be a link-scope multicast + address or a unicast address. + + A responder MUST select a source address for responses that is + assigned on the interface on which the query was received. The + destination address of an LLMNR response MUST be a unicast address. + + On receiving an LLMNR query, the responder MUST check whether it was + sent to a LLMNR multicast addresses defined in Section 2. If it was + sent to another multicast address, then the query MUST be silently + discarded. + + + +Aboba, Thaler & Esibov Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + Section 2.4 discusses use of TCP for LLMNR queries and responses. In + composing an LLMNR query using TCP, the sender MUST set the Hop Limit + field in the IPv6 header and the TTL field in the IPv4 header of the + response to one (1). The responder SHOULD set the TTL or Hop Limit + settings on the TCP listen socket to one (1) so that SYN-ACK packets + will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This + prevents an incoming connection from off-link since the sender will + not receive a SYN-ACK from the responder. + + For UDP queries and responses, the Hop Limit field in the IPv6 header + and the TTL field in the IPV4 header MAY be set to any value. + However, it is RECOMMENDED that the value 255 be used for + compatibility with early implementations of [RFC3927]. + + Implementation note: + + In the sockets API for IPv4 [POSIX], the IP_TTL and + IP_MULTICAST_TTL socket options are used to set the TTL of + outgoing unicast and multicast packets. The IP_RECVTTL socket + option is available on some platforms to retrieve the IPv4 TTL of + received packets with recvmsg(). [RFC2292] specifies similar + options for setting and retrieving the IPv6 Hop Limit. + +2.6. Responder Responsibilities + + It is the responsibility of the responder to ensure that RRs returned + in LLMNR responses MUST only include values that are valid on the + local interface, such as IPv4 or IPv6 addresses valid on the local + link or names defended using the mechanism described in Section 4. + IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local + addresses are defined in [RFC2373]. In particular: + + [a] If a link-scope IPv6 address is returned in a AAAA RR, + that address MUST be valid on the local link over which + LLMNR is used. + + [b] If an IPv4 address is returned, it MUST be reachable + through the link over which LLMNR is used. + + [c] If a name is returned (for example in a CNAME, MX + or SRV RR), the name MUST be resolvable on the local + link over which LLMNR is used. + + Where multiple addresses represent valid responses to a query, the + order in which the addresses are returned is as follows: + + [d] If the source address of the query is a link-scope address, + then the responder SHOULD include a link-scope address first + + + +Aboba, Thaler & Esibov Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + in the response, if available. + + [e] If the source address of the query is a routable address, + then the responder MUST include a routable address first + in the response, if available. + +2.7. Retransmission and Jitter + + An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine + when to retransmit an LLMNR query. An LLMNR sender SHOULD either + estimate the LLMNR_TIMEOUT for each interface, or set a reasonably + high initial timeout. Suggested constants are described in Section + 7. + + If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, + then a sender SHOULD repeat the transmission of the query in order to + assure that it was received by a host capable of responding to it. + An LLMNR query SHOULD NOT be sent more than three times. + + Where LLMNR queries are sent using TCP, retransmission is handled by + the transport layer. Queries with the 'C' bit set MUST be sent using + multicast UDP and MUST NOT be retransmitted. + + An LLMNR sender cannot know in advance if a query sent using + multicast will receive no response, one response, or more than one + response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response + has been received, or if it is necessary to collect all potential + responses, such as if a uniqueness verification query is being made. + Otherwise an LLMNR sender SHOULD consider a multicast query answered + after the first response is received, if that response has the 'C' + bit clear. + + However, if the first response has the 'C' bit set, then the sender + SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect + all possible responses. When multiple valid answers are received, + they may first be concatenated, and then treated in the same manner + that multiple RRs received from the same DNS server would. A unicast + query sender considers the query answered after the first response is + received. + + Since it is possible for a response with the 'C' bit clear to be + followed by a response with the 'C' bit set, an LLMNR sender SHOULD + be prepared to process additional responses for the purposes of + conflict detection, even after it has considered a query answered. + + In order to avoid synchronization, the transmission of each LLMNR + query and response SHOULD delayed by a time randomly selected from + the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by + + + +Aboba, Thaler & Esibov Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + responders responding with names which they have previously + determined to be UNIQUE (see Section 4 for details). + +2.8. DNS TTL + + The responder should insert a pre-configured TTL value in the records + returned in an LLMNR response. A default value of 30 seconds is + RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc + networks), the TTL value may need to be reduced. + + Due to the TTL minimalization necessary when caching an RRset, all + TTLs in an RRset MUST be set to the same value. + +2.9. Use of the Authority and Additional Sections + + Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a + concept of delegation. In LLMNR, the NS resource record type may be + stored and queried for like any other type, but it has no special + delegation semantics as it does in the DNS. Responders MAY have NS + records associated with the names for which they are authoritative, + but they SHOULD NOT include these NS records in the authority + sections of responses. + + Responders SHOULD insert an SOA record into the authority section of + a negative response, to facilitate negative caching as specified in + [RFC2308]. The TTL of this record is set from the minimum of the + MINIMUM field of the SOA record and the TTL of the SOA itself, and + indicates how long a resolver may cache the negative answer. The + owner name of the SOA record (MNAME) MUST be set to the query name. + The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored + by senders. Negative responses without SOA records SHOULD NOT be + cached. + + In LLMNR, the additional section is primarily intended for use by + EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set, + senders MAY only include pseudo RR-types in the additional section of + a query; unless the 'C' bit is set, responders MUST ignore the + additional section of queries containing other RR types. + + In queries where the 'C' bit is set, the sender SHOULD include the + conflicting RRs in the additional section. Since conflict + notifications are advisory, responders SHOULD log information from + the additional section, but otherwise MUST ignore the additional + section. + + Senders MUST NOT cache RRs from the authority or additional section + of a response as answers, though they may be used for other purposes + such as negative caching. + + + +Aboba, Thaler & Esibov Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +3. Usage Model + + LLMNR is a peer-to-peer name resolution protocol that is not intended + as a replacement for DNS; rather, it enables name resolution in + scenarios in which conventional DNS name resolution is not possible. + This includes situations in which hosts are not configured with the + address of a DNS server; where the DNS server is unavailable or + unreachable; where there is no DNS server authoritative for the name + of a host, or where the authoritative DNS server does not have the + desired RRs. + + By default, an LLMNR sender SHOULD send LLMNR queries only for + single-label names. In order to reduce unnecessary DNS queries, stub + resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS + queries for single-label names. An LLMNR sender SHOULD NOT be + enabled to send a query for any name, except where security + mechanisms (described in Section 5.3) can be utilized. + + Regardless of whether security mechanisms can be utilized, LLMNR + queries SHOULD NOT be sent unless one of the following conditions are + met: + + [1] No manual or automatic DNS configuration has been performed. + If DNS server address(es) have been configured, a + host SHOULD attempt to reach DNS servers over all protocols + on which DNS server address(es) are configured, prior to sending + LLMNR queries. For dual stack hosts configured with DNS server + address(es) for one protocol but not another, this implies that + DNS queries SHOULD be sent over the protocol configured with + a DNS server, prior to sending LLMNR queries. + + [2] All attempts to resolve the name via DNS on all interfaces + have failed after exhausting the searchlist. This can occur + because DNS servers did not respond, or because they + responded to DNS queries with RCODE=3 (Authoritative Name + Error) or RCODE=0, and an empty answer section. Where a + single resolver call generates DNS queries for A and AAAA RRs, + an implementation MAY choose not to send LLMNR queries if any + of the DNS queries is successful. An LLMNR query SHOULD only + be sent for the originally requested name; a searchlist + is not used to form additional LLMNR queries. + + Since LLMNR is a secondary name resolution mechanism, its usage is in + part determined by the behavior of DNS implementations. In general, + robust DNS resolver implementations are more likely to avoid + unnecessary LLMNR queries. + + As noted in [DNSPerf], even when DNS servers are configured, a + + + +Aboba, Thaler & Esibov Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + significant fraction of DNS queries do not receive a response, or + result in negative responses due to missing inverse mappings or NS + records that point to nonexistent or inappropriate hosts. This has + the potential to result in a large number of unnecessary LLMNR + queries. + + [RFC1536] describes common DNS implementation errors and fixes. If + the proposed fixes are implemented, unnecessary LLMNR queries will be + reduced substantially, and so implementation of [RFC1536] is + recommended. + + For example, [RFC1536] Section 1 describes issues with retransmission + and recommends implementation of a retransmission policy based on + round trip estimates, with exponential back-off. [RFC1536] Section 4 + describes issues with failover, and recommends that resolvers try + another server when they don't receive a response to a query. These + policies are likely to avoid unnecessary LLMNR queries. + + [RFC1536] Section 3 describes zero answer bugs, which if addressed + will also reduce unnecessary LLMNR queries. + + [RFC1536] Section 6 describes name error bugs and recommended + searchlist processing that will reduce unnecessary RCODE=3 + (authoritative name) errors, thereby also reducing unnecessary LLMNR + queries. + + If error responses are received from both DNS and LLMNR, then the + lowest RCODE value should be returned. For example, if either DNS or + LLMNR receives a response with RCODE=0, then this should returned to + the caller. + +3.1. LLMNR Configuration + + LLMNR usage MAY be configured manually or automatically on a per + interface basis. By default, LLMNR responders SHOULD be enabled on + all interfaces, at all times. Enabling LLMNR for use in situations + where a DNS server has been configured will result in a change in + default behavior without a simultaneous update to configuration + information. Where this is considered undesirable, LLMNR SHOULD NOT + be enabled by default, so that hosts will neither listen on the link- + scope multicast address, nor will they send queries to that address. + + Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is + possible for a dual stack host to be configured with the address of a + DNS server over IPv4, while remaining unconfigured with a DNS server + suitable for use over IPv6. + + In these situations, a dual stack host will send AAAA queries to the + + + +Aboba, Thaler & Esibov Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + configured DNS server over IPv4. However, an IPv6-only host + unconfigured with a DNS server suitable for use over IPv6 will be + unable to resolve names using DNS. Automatic IPv6 DNS configuration + mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely + deployed, and not all DNS servers support IPv6. Therefore lack of + IPv6 DNS configuration may be a common problem in the short term, and + LLMNR may prove useful in enabling link-local name resolution over + IPv6. + + Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], + IPv6-only hosts may not be configured with a DNS server. Where there + is no DNS server authoritative for the name of a host or the + authoritative DNS server does not support dynamic client update over + IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not + be able to do DNS dynamic update, and other hosts will not be able to + resolve its name. + + For example, if the configured DNS server responds to a AAAA RR query + sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or + RCODE=0 and an empty answer section, then a AAAA RR query sent using + LLMNR over IPv6 may be successful in resolving the name of an + IPv6-only host on the local link. + + Similarly, if a DHCPv4 server is available providing DNS server + configuration, and DNS server(s) exist which are authoritative for + the A RRs of local hosts and support either dynamic client update + over IPv4 or DHCPv4-based dynamic update, then the names of local + IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no + DNS server is authoritative for the names of local hosts, or the + authoritative DNS server(s) do not support dynamic update, then LLMNR + enables linklocal name resolution over IPv4. + + Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to + configure LLMNR on an interface. The LLMNR Enable Option, described + in [LLMNREnable], can be used to explicitly enable or disable use of + LLMNR on an interface. The LLMNR Enable Option does not determine + whether or in which order DNS itself is used for name resolution. + The order in which various name resolution mechanisms should be used + can be specified using the Name Service Search Option (NSSO) for DHCP + [RFC2937], using the LLMNR Enable Option code carried in the NSSO + data. + + It is possible that DNS configuration mechanisms will go in and out + of service. In these circumstances, it is possible for hosts within + an administrative domain to be inconsistent in their DNS + configuration. + + For example, where DHCP is used for configuring DNS servers, one or + + + +Aboba, Thaler & Esibov Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + more DHCP servers can fail. As a result, hosts configured prior to + the outage will be configured with a DNS server, while hosts + configured after the outage will not. Alternatively, it is possible + for the DNS configuration mechanism to continue functioning while + configured DNS servers fail. + + An outage in the DNS configuration mechanism may result in hosts + continuing to use LLMNR even once the outage is repaired. Since + LLMNR only enables linklocal name resolution, this represents a + degradation in capabilities. As a result, hosts without a configured + DNS server may wish to periodically attempt to obtain DNS + configuration if permitted by the configuration mechanism in use. In + the absence of other guidance, a default retry interval of one (1) + minute is RECOMMENDED. + +4. Conflict Resolution + + By default, a responder SHOULD be configured to behave as though its + name is UNIQUE on each interface on which LLMNR is enabled. However, + it is also possible to configure multiple responders to be + authoritative for the same name. For example, multiple responders + MAY respond to a query for an A or AAAA type record for a cluster + name (assigned to multiple hosts in the cluster). + + To detect duplicate use of a name, an administrator can use a name + resolution utility which employs LLMNR and lists both responses and + responders. This would allow an administrator to diagnose behavior + and potentially to intervene and reconfigure LLMNR responders who + should not be configured to respond to the same name. + +4.1. Uniqueness Verification + + Prior to sending an LLMNR response with the 'T' bit clear, a + responder configured with a UNIQUE name MUST verify that there is no + other host within the scope of LLMNR query propagation that is + authoritative for the same name on that interface. + + Once a responder has verified that its name is UNIQUE, if it receives + an LLMNR query for that name, with the 'C' bit clear, it MUST + respond, with the 'T' bit clear. Prior to verifying that its name is + UNIQUE, a responder MUST set the 'T' bit in responses. + + Uniqueness verification is carried out when the host: + + - starts up or is rebooted + - wakes from sleep (if the network interface was inactive + during sleep) + - is configured to respond to LLMNR queries on an interface + + + +Aboba, Thaler & Esibov Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + enabled for transmission and reception of IP traffic + - is configured to respond to LLMNR queries using additional + UNIQUE resource records + - verifies the acquisition of a new IP address and configuration + on an interface + + To verify uniqueness, a responder MUST send an LLMNR query with the + 'C' bit clear, over all protocols on which it responds to LLMNR + queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify + uniqueness of a name by sending a query for the name with type='ANY'. + + If no response is received, the sender retransmits the query, as + specified in Section 2.7. If a response is received, the sender MUST + check if the source address matches the address of any of its + interfaces; if so, then the response is not considered a conflict, + since it originates from the sender. To avoid triggering conflict + detection, a responder that detects that it is connected to the same + link on multiple interfaces SHOULD set the 'C' bit in responses. + + If a response is received with the 'T' bit clear, the responder MUST + NOT use the name in response to LLMNR queries received over any + protocol (IPv4 or IPv6). If a response is received with the 'T' bit + set, the responder MUST check if the source IP address in the + response, interpreted as an unsigned integer, is less than the source + IP address in the query. If so, the responder MUST NOT use the name + in response to LLMNR queries received over any protocol (IPv4 or + IPv6). For the purpose of uniqueness verification, the contents of + the answer section in a response is irrelevant. + + Periodically carrying out uniqueness verification in an attempt to + detect name conflicts is not necessary, wastes network bandwidth, and + may actually be detrimental. For example, if network links are + joined only briefly, and are separated again before any new + communication is initiated, temporary conflicts are benign and no + forced reconfiguration is required. LLMNR responders SHOULD NOT + periodically attempt uniqueness verification. + +4.2. Conflict Detection and Defense + + Hosts on disjoint network links may configure the same name for use + with LLMNR. If these separate network links are later joined or + bridged together, then there may be multiple hosts which are now on + the same link, trying to use the same name. + + In order to enable ongoing detection of name conflicts, when an LLMNR + sender receives multiple LLMNR responses to a query, it MUST check if + the 'C' bit is clear in any of the responses. If so, the sender + SHOULD send another query for the same name, type and class, this + + + +Aboba, Thaler & Esibov Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + time with the 'C' bit set, with the potentially conflicting resource + records included in the additional section. + + Queries with the 'C' bit set are considered advisory and responders + MUST verify the existence of a conflict before acting on it. A + responder receiving a query with the 'C' bit set MUST NOT respond. + + If the query is for a UNIQUE name, then the responder MUST send its + own query for the same name, type and class, with the 'C' bit clear. + If a response is received, the sender MUST check if the source + address matches the address of any of its interfaces; if so, then the + response is not considered a conflict, since it originates from the + sender. To avoid triggering conflict detection, a responder that + detects that it is connected to the same link on multiple interfaces + SHOULD set the 'C' bit in responses. + + An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD + log them. Upon detecting a conflict, an LLMNR responder MUST + immediately stop using the conflicting name in response to LLMNR + queries received over any supported protocol, if the source IP + address in the response, interpreted as an unsigned integer, is less + than the source IP address in the uniqueness verification query. + + After stopping the use of a name, the responder MAY elect to + configure a new name. However, since name reconfiguration may be + disruptive, this is not required, and a responder may have been + configured to respond to multiple names so that alternative names may + already be available. A host that has stopped the use of a name may + attempt uniqueness verification again after the expiration of the TTL + of the conflicting response. + +4.3. Considerations for Multiple Interfaces + + A multi-homed host may elect to configure LLMNR on only one of its + active interfaces. In many situations this will be adequate. + However, should a host need to configure LLMNR on more than one of + its active interfaces, there are some additional precautions it MUST + take. Implementers who are not planning to support LLMNR on multiple + interfaces simultaneously may skip this section. + + Where a host is configured to issue LLMNR queries on more than one + interface, each interface maintains its own independent LLMNR + resolver cache, containing the responses to LLMNR queries. + + A multi-homed host checks the uniqueness of UNIQUE records as + described in Section 4. The situation is illustrated in figure 1. + + + + + +Aboba, Thaler & Esibov Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + Figure 1. Link-scope name conflict + + In this situation, the multi-homed myhost will probe for, and defend, + its host name on both interfaces. A conflict will be detected on one + interface, but not the other. The multi-homed myhost will not be + able to respond with a host RR for "myhost" on the interface on the + right (see Figure 1). The multi-homed host may, however, be + configured to use the "myhost" name on the interface on the left. + + Since names are only unique per-link, hosts on different links could + be using the same name. If an LLMNR client sends requests over + multiple interfaces, and receives replies from more than one, the + result returned to the client is defined by the implementation. The + situation is illustrated in figure 2. + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + Figure 2. Off-segment name conflict + + If host myhost is configured to use LLMNR on both interfaces, it will + send LLMNR queries on both interfaces. When host myhost sends a + query for the host RR for name "A" it will receive a response from + hosts on both interfaces. + + Host myhost cannot distinguish between the situation shown in Figure + 2, and that shown in Figure 3 where no conflict exists. + + [A] + | | + ----- ----- + | | + [myhost] + + Figure 3. Multiple paths to same host + + This illustrates that the proposed name conflict resolution mechanism + does not support detection or resolution of conflicts between hosts + on different links. This problem can also occur with DNS when a + multi-homed host is connected to two different networks with + separated name spaces. It is not the intent of this document to + address the issue of uniqueness of names within DNS. + + + +Aboba, Thaler & Esibov Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +4.4. API Issues + + [RFC2553] provides an API which can partially solve the name + ambiguity problem for applications written to use this API, since the + sockaddr_in6 structure exposes the scope within which each scoped + address exists, and this structure can be used for both IPv4 (using + v4-mapped IPv6 addresses) and IPv6 addresses. + + Following the example in Figure 2, an application on 'myhost' issues + the request getaddrinfo("A", ...) with ai_family=AF_INET6 and + ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both + interfaces and the resolver library will return a list containing + multiple addrinfo structures, each with an associated sockaddr_in6 + structure. This list will thus contain the IPv4 and IPv6 addresses + of both hosts responding to the name 'A'. Link-local addresses will + have a sin6_scope_id value that disambiguates which interface is used + to reach the address. Of course, to the application, Figures 2 and 3 + are still indistinguishable, but this API allows the application to + communicate successfully with any address in the list. + +5. Security Considerations + + LLMNR is a peer-to-peer name resolution protocol designed for use on + the local link. While LLMNR limits the vulnerability of responders + to off-link senders, it is possible for an off-link responder to + reach a sender. + + In scenarios such as public "hotspots" attackers can be present on + the same link. These threats are most serious in wireless networks + such as 802.11, since attackers on a wired network will require + physical access to the network, while wireless attackers may mount + attacks from a distance. Link-layer security such as [IEEE-802.11i] + can be of assistance against these threats if it is available. + + This section details security measures available to mitigate threats + from on and off-link attackers. + +5.1. Denial of Service + + Attackers may take advantage of LLMNR conflict detection by + allocating the same name, denying service to other LLMNR responders + and possibly allowing an attacker to receive packets destined for + other hosts. By logging conflicts, LLMNR responders can provide + forensic evidence of these attacks. + + An attacker may spoof LLMNR queries from a victim's address in order + to mount a denial of service attack. Responders setting the IPv6 Hop + Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP + + + +Aboba, Thaler & Esibov Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + response may be able to reach the victim across the Internet. + + While LLMNR responders only respond to queries for which they are + authoritative and LLMNR does not provide wildcard query support, an + LLMNR response may be larger than the query, and an attacker can + generate multiple responses to a query for a name used by multiple + responders. A sender may protect itself against unsolicited + responses by silently discarding them as rapidly as possible. + +5.2. Spoofing + + LLMNR is designed to prevent reception of queries sent by an off-link + attacker. LLMNR requires that responders receiving UDP queries check + that they are sent to a link-scope multicast address. However, it is + possible that some routers may not properly implement link-scope + multicast, or that link-scope multicast addresses may leak into the + multicast routing system. To prevent successful setup of TCP + connections by an off-link sender, responders receiving a TCP SYN + reply with a TCP SYN-ACK with TTL set to one (1). + + While it is difficult for an off-link attacker to send an LLMNR query + to a responder, it is possible for an off-link attacker to spoof a + response to a query (such as an A or AAAA query for a popular + Internet host), and by using a TTL or Hop Limit field larger than one + (1), for the forged response to reach the LLMNR sender. Since the + forged response will only be accepted if it contains a matching ID + field, choosing a pseudo-random ID field within queries provides some + protection against off-link responders. + + Since LLMNR queries can be sent when DNS server(s) do not respond, an + attacker can execute a denial of service attack on the DNS server(s) + and then poison the LLMNR cache by responding to an LLMNR query with + incorrect information. As noted in "Threat Analysis of the Domain + Name System (DNS)" [RFC3833] these threats also exist with DNS, since + DNS response spoofing tools are available that can allow an attacker + to respond to a query more quickly than a distant DNS server. + However, while switched networks or link layer security may make it + difficult for an on-link attacker to snoop unicast DNS queries, + multicast LLMNR queries are propagated to all hosts on the link, + making it possible for an on-link attacker to spoof LLMNR responses + without having to guess the value of the ID field in the query. + + Since LLMNR queries are sent and responded to on the local-link, an + attacker will need to respond more quickly to provide its own + response prior to arrival of the response from a legitimate + responder. If an LLMNR query is sent for an off-link host, spoofing + a response in a timely way is not difficult, since a legitimate + response will never be received. + + + +Aboba, Thaler & Esibov Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + This vulnerability can be reduced by limiting use of LLMNR to + resolution of single-label names as described in Section 3, or by + implementation of authentication (see Section 5.3). + +5.3. Authentication + + LLMNR is a peer-to-peer name resolution protocol, and as a result, + it is often deployed in situations where no trust model can be + assumed. Where a pre-arranged security configuration is possible, + the following security mechanisms may be used: + +[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0) + [RFC2931] security mechanisms. "DNS Name Service based on Secure + Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes + the use of TSIG to secure LLMNR, based on group keys. While group + keys can be used to demonstrate membership in a group, they do not + protect against forgery by an attacker that is a member of the + group. + +[b] IPsec ESP with a null-transform MAY be used to authenticate unicast + LLMNR queries and responses or LLMNR responses to multicast + queries. In a small network without a certificate authority, this + can be most easily accomplished through configuration of a group + pre-shared key for trusted hosts. As with TSIG, this does not + protect against forgery by an attacker with access to the group + pre-shared key. + +[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to + support DNSSEC, LLMNR implementations MAY be configured with trust + anchors, or they MAY make use of keys obtained from DNS queries. + Since LLMNR does not support "delegated trust" (CD or AD bits), + LLMNR implementations cannot make use of DNSSEC unless they are + DNSSEC-aware and support validation. Unlike approaches [a] or [b], + DNSSEC permits a responder to demonstrate ownership of a name, not + just membership within a trusted group. As a result, it enables + protection against forgery. + +5.4. Cache and Port Separation + + In order to prevent responses to LLMNR queries from polluting the DNS + cache, LLMNR implementations MUST use a distinct, isolated cache for + LLMNR on each interface. The use of separate caches is most + effective when LLMNR is used as a name resolution mechanism of last + resort, since this minimizes the opportunities for poisoning the + LLMNR cache, and decreases reliance on it. + + LLMNR operates on a separate port from DNS, reducing the likelihood + that a DNS server will unintentionally respond to an LLMNR query. + + + +Aboba, Thaler & Esibov Standards Track [Page 24] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + + If LLMNR is given higher priority than DNS among the enabled name + resolution mechanisms, a denial of service attack on the DNS server + would not be necessary in order to poison the LLMNR cache, since + LLMNR queries would be sent even when the DNS server is available. + In addition, the LLMNR cache, once poisoned, would take precedence + over the DNS cache, eliminating the benefits of cache separation. As + a result, LLMNR SHOULD NOT be used as a primary name resolution + mechanism. + +6. IANA Considerations + + LLMNR requires allocation of port 5355 for both TCP and UDP. + + LLMNR requires allocation of link-scope multicast IPv4 address + 224.0.0.252, as well as link-scope multicast IPv6 address + FF02:0:0:0:0:0:1:3. + + This specification creates two new name spaces: the LLMNR namespace + and the reserved bits in the LLMNR header. The reserved bits in the + LLMNR header are allocated by IETF Consensus, in accordance with BCP + 26 [RFC2434]. + + In order to to avoid creating any new administrative procedures, + administration of the LLMNR namespace will piggyback on the + administration of the DNS namespace. + + The rights to use a fully qualified domain name (FQDN) within LLMNR + are obtained coincident with acquiring the rights to use that name + within DNS. Those wishing to use a FQDN within LLMNR should first + acquire the rights to use the corresponding FQDN within DNS. Using a + FQDN within LLMNR without ownership of the corresponding name in DNS + creates the possibility of conflict and therefore is discouraged. + + LLMNR responders may self-allocate a name within the single-label + name space, first defined in [RFC1001]. Since single-label names are + not unique, no registration process is required. + +7. Constants + + The following timing constants are used in this protocol; they are + not intended to be user configurable. + + JITTER_INTERVAL 100 ms + LLMNR_TIMEOUT 1 second (if set statically on all interfaces) + 100 ms (IEEE 802 media, including IEEE 802.11) + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 25] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +8. References + +8.1. Normative References + +[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport: Concepts and Methods", RFC + 1001, March 1987. + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + +[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + +[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + +8.2. Informative References + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of + Caching", IEEE/ACM Transactions on Networking, Volume 10, + Number 5, pp. 589, October 2002. + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + Internet draft (work in progress), draft-ietf-ipv6-dns- + discovery-07.txt, October 2002. + + + + +Aboba, Thaler & Esibov Standards Track [Page 26] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[IEEE-802.11i] + Institute of Electrical and Electronics Engineers, "Supplement + to Standard for Telecommunications and Information Exchange + Between Systems - LAN/MAN Specific Requirements - Part 11: + Wireless LAN Medium Access Control (MAC) and Physical Layer + (PHY) Specifications: Specification for Enhanced Security", + IEEE 802.11i, July 2004. + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + +[LLMNRSec] + Jeong, J., Park, J. and H. Kim, "DNS Name Service based on + Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT + 2004, Phoenix Park, Korea, February 9-11, 2004. + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + +[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + +[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + +Aboba, Thaler & Esibov Standards Track [Page 27] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of Link-Local IPv4 Addresses", RFC 3927, October 2004. + +[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirement", RFC 4033, March + 2005. + +Acknowledgments + + This work builds upon original work done on multicast DNS by Bill + Manning and Bill Woodcock. Bill Manning's work was funded under + DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge + their contribution to the current specification. Constructive input + has also been received from Mark Andrews, Rob Austein, Randy Bush, + Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur + Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, + Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, + Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike + St. Johns, Sander Van-Valkenburg, and Brian Zill. + +Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 706 6605 + EMail: bernarda@microsoft.com + + Dave Thaler + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 703 8835 + EMail: dthaler@microsoft.com + + Levon Esibov + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + EMail: levone@microsoft.com + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 28] + + + + + +INTERNET-DRAFT LLMNR 16 April 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. + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 29] + + + + + +INTERNET-DRAFT LLMNR 16 April 2006 + + +Open Issues + + Open issues with this specification are tracked on the following web + site: + + http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba, Thaler & Esibov Standards Track [Page 30] + + + diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt new file mode 100644 index 0000000..90d1a06 --- /dev/null +++ b/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/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt new file mode 100644 index 0000000..e169da8 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-07.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT DSA Information in the DNS +OBSOLETES: RFC 2536 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: September 2006 March 2006 + + + DSA Keying and Signature Information in the DNS + --- ------ --- --------- ----------- -- --- --- + <draft-ietf-dnsext-rfc2536bis-dsa-07.txt> + Donald E. Eastlake 3rd + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this document is unlimited. Comments should be sent + to the DNS extensions working group mailing list + <namedroppers@ops.ietf.org>. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + The standard method of encoding US Government Digital Signature + Algorithm keying and signature information for use in the Domain Name + System is specified. + + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DSA Information in the DNS + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DSA Keying Information..................................3 + 3. DSA Signature Information...............................4 + 4. Performance Considerations..............................4 + 5. Security Considerations.................................5 + 6. IANA Considerations.....................................5 + Copyright, Disclaimer, and Additional IPR Provisions.......5 + + Normative References.......................................7 + Informative References.....................................7 + + Author's Address...........................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DSA Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC 4033, 4034, 4035] and additional work is underway which would + require the storage of keying and signature information in the DNS. + + This document describes how to encode US Government Digital Signature + Algorithm (DSA) keys and signatures in the DNS. Familiarity with the + US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier]. + + + +2. DSA Keying Information + + When DSA public keys are stored in the DNS, the structure of the + relevant part of the RDATA part of the RR being used is the fields + listed below in the order given. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR such as RRSIG which signs + and authenticates the RR containing the keying information. + + Field Size + ----- ---- + T 1 octet + Q 20 octets + P 64 + T*8 octets + G 64 + T*8 octets + Y 64 + T*8 octets + + As described in [FIPS 186-2] and [Schneier], T is a key size + parameter chosen such that 0 <= T <= 8. (The meaning if the T octet + is greater than 8 is reserved and the remainder of the data may have + a different format in that case.) Q is a prime number selected at + key generation time such that 2**159 < Q < 2**160. Thus Q is always + 20 octets long and, as with all other fields, is stored in "big- + endian" network order. P, G, and Y are calculated as directed by the + [FIPS 186-2] key generation algorithm [Schneier]. P is in the range + 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G + and Y are quantities modulo P and so can be up to the same length as + P and are allocated fixed size fields with the same number of octets + as P. + + During the key generation process, a random number X must be + generated such that 1 <= X <= Q-1. X is the private key and is used + in the final step of public key generation where Y is computed as + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DSA Information in the DNS + + + Y = G**X mod P + + + +3. DSA Signature Information + + The portion of the RDATA area used for US Digital Signature Algorithm + signature information is shown below with fields in the order they + are listed and the contents of each multi-octet field in "big-endian" + network order. + + Field Size + ----- ---- + T 1 octet + R 20 octets + S 20 octets + + First, the data signed must be determined. Then the following steps + are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as + specified in the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate a random K such that 0 < K < Q. + + R = ( G**K mod P ) mod Q + + S = ( K**(-1) * (hash + X*R) ) mod Q + + For information on the SHA-1 hash function see [FIPS 180-2] and [RFC + 3174]. + + Since Q is 160 bits long, R and S can not be larger than 20 octets, + which is the space allocated. + + T is copied from the public key. It is not logically necessary in + the SIG but is present so that values of T > 8 can more conveniently + be used as an escape for extended versions of DSA or other algorithms + as later standardized. + + + +4. Performance Considerations + + General signature generation speeds are roughly the same for RSA [RFC + 3110] and DSA. With sufficient pre-computation, signature generation + with DSA is faster than RSA. Key generation is also faster for DSA. + However, signature verification is an order of magnitude slower than + RSA when the RSA public exponent is chosen to be small, as is + recommended for some applications. + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DSA Information in the DNS + + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient, it + is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying and/or signature + inforamtion consistent with adequate security. + + + +5. Security Considerations + + Keys retrieved from the DNS should not be trusted unless (1) they + have been securely obtained from a secure resolver or independently + verified by the user and (2) this secure resolver and secure + obtainment or independent verification conform to security policies + acceptable to the user. As with all cryptographic algorithms, + evaluating the necessary strength of the key is essential and + dependent on local policy. + + The key size limitation of a maximum of 1024 bits ( T = 8 ) in the + current DSA standard may limit the security of DSA. For particular + applications, implementors are encouraged to consider the range of + available algorithms and key sizes. + + DSA assumes the ability to frequently generate high quality random + numbers. See [random] for guidance. DSA is designed so that if + biased rather than random numbers are used, high bandwidth covert + channels are possible. See [Schneier] and more recent research. The + leakage of an entire DSA private key in only two DSA signatures has + been demonstrated. DSA provides security only if trusted + implementations, including trusted random number generation, are + used. + + + +6. IANA Considerations + + Allocation of meaning to values of the T parameter that are not + defined herein (i.e., > 8 ) requires an IETF standards actions. It + is intended that values unallocated herein be used to cover future + extensions of the DSS standard. + + + +Copyright, Disclaimer, and Additional IPR Provisions + + Copyright (C) The Internet Society (2006). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DSA Information in the DNS + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DSA Information in the DNS + + +Normative References + + [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital + Signature Standard, 27 January 2000. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Informative References + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, 11/01/1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, 11/01/1987. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS)", D. Eastlake 3rd. May 2001. + + [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. + Jones, September 2001. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. + + [Schneier] - "Applied Cryptography Second Edition: protocols, + algorithms, and source code in C" (second edition), Bruce Schneier, + 1996, John Wiley and Sons, ISBN 0-471-11709-9. + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DSA Information in the DNS + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Labortories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554(w) + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in September 2006. + + Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt new file mode 100644 index 0000000..f6e8588 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-07.txt @@ -0,0 +1,580 @@ + +INTERNET-DRAFT Diffie-Hellman Information in the DNS +OBSOLETES: RFC 2539 Donald E. Eastlake 3rd + Motorola Laboratories +Expires: September 2006 March 2006 + + + + + Storage of Diffie-Hellman Keying Information in the DNS + ------- -- -------------- ------ ----------- -- --- --- + <draft-ietf-dnsext-rfc2539bis-dhk-07.txt> + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this document is unlimited. Comments should be sent + to the DNS extensions working group mailing list + <namedroppers@ops.ietf.org>. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + The standard method for encoding Diffie-Hellman keys in the Domain + Name System is specified. + + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Acknowledgements + + Part of the format for Diffie-Hellman keys and the description + thereof was taken from a work in progress by Ashar Aziz, Tom Markson, + and Hemma Prafullchandra. In addition, the following persons + provided useful comments that were incorporated into the predecessor + of this document: Ran Atkinson, Thomas Narten. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 1.1 About This Document....................................3 + 1.2 About Diffie-Hellman...................................3 + 2. Encoding Diffie-Hellman Keying Information..............4 + 3. Performance Considerations..............................5 + 4. IANA Considerations.....................................5 + 5. Security Considerations.................................5 + Copyright, Disclaimer, and Additional IPR Provisions.......5 + + Normative References.......................................7 + Informative Refences.......................................7 + + Author's Address...........................................8 + Expiration and File Name...................................8 + + Appendix A: Well known prime/generator pairs...............9 + A.1. Well-Known Group 1: A 768 bit prime..................9 + A.2. Well-Known Group 2: A 1024 bit prime.................9 + A.3. Well-Known Group 3: A 1536 bit prime................10 + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + similar information [RFC 1034, 1035]. The DNS has been extended to + include digital signatures and cryptographic keys as described in + [RFC 4033, 4034, 4035] and additonal work is underway which would use + the storage of keying information in the DNS. + + + +1.1 About This Document + + This document describes how to store Diffie-Hellman keys in the DNS. + Familiarity with the Diffie-Hellman key exchange algorithm is assumed + [Schneier, RFC 2631]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. + + + +1.2 About Diffie-Hellman + + Diffie-Hellman requires two parties to interact to derive keying + information which can then be used for authentication. Thus Diffie- + Hellman is inherently a key agreement algorithm. As a result, no + format is defined for Diffie-Hellman "signature information". For + example, assume that two parties have local secrets "i" and "j". + Assume they each respectively calculate X and Y as follows: + + X = g**i ( mod p ) + + Y = g**j ( mod p ) + + They exchange these quantities and then each calculates a Z as + follows: + + Zi = Y**i ( mod p ) + + Zj = X**j ( mod p ) + + Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared + secret between the two parties that an adversary who does not know i + or j will not be able to learn from the exchanged messages (unless + the adversary can derive i or j by performing a discrete logarithm + mod p which is hard for strong p and g). + + The private key for each party is their secret i (or j). The public + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + key is the pair p and g, which is the same for both parties, and + their individual X (or Y). + + For further information about Diffie-Hellman and precautions to take + in deciding on a p and g, see [RFC 2631]. + + + +2. Encoding Diffie-Hellman Keying Information + + When Diffie-Hellman keys appear within the RDATA portion of a RR, + they are encoded as shown below. + + The period of key validity is not included in this data but is + indicated separately, for example by an RR such as RRSIG which signs + and authenticates the RR containing the keying information. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | prime length (or flag) | prime (p) (or special) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / prime (p) (variable length) | generator length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | generator (g) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | public value length | public value (variable length)/ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / public value (g^i mod p) (variable length) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Prime length is the length of the Diffie-Hellman prime (p) in bytes + if it is 16 or greater. Prime contains the binary representation of + the Diffie-Hellman prime with most significant byte first (i.e., in + network order). If "prime length" field is 1 or 2, then the "prime" + field is actually an unsigned index into a table of 65,536 + prime/generator pairs and the generator length SHOULD be zero. See + Appedix A for defined table entries and Section 4 for information on + allocating additional table entries. The meaning of a zero or 3 + through 15 value for "prime length" is reserved. + + Generator length is the length of the generator (g) in bytes. + Generator is the binary representation of generator with most + significant byte first. PublicValueLen is the Length of the Public + Value (g**i (mod p)) in bytes. PublicValue is the binary + representation of the DH public value with most significant byte + first. + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +3. Performance Considerations + + Current DNS implementations are optimized for small transfers, + typically less than 512 bytes including DNS overhead. Larger + transfers will perform correctly and extensions have been + standardized [RFC 2671] to make larger transfers more efficient. But + it is still advisable at this time to make reasonable efforts to + minimize the size of RR sets containing keying information consistent + with adequate security. + + + +4. IANA Considerations + + Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires + an IETF consensus as defined in [RFC 2434]. + + Well known prime/generator pairs number 0x0000 through 0x07FF can + only be assigned by an IETF standards action. [RFC 2539], the + Proposed Standard predecessor of this document, assigned 0x0001 + through 0x0002. This document additionally assigns 0x0003. Pairs + number 0s0800 through 0xBFFF can be assigned based on RFC + documentation. Pairs number 0xC000 through 0xFFFF are available for + private use and are not centrally coordinated. Use of such private + pairs outside of a closed environment may result in conflicts and/or + security failures. + + + +5. Security Considerations + + Keying information retrieved from the DNS should not be trusted + unless (1) it has been securely obtained from a secure resolver or + independently verified by the user and (2) this secure resolver and + secure obtainment or independent verification conform to security + policies acceptable to the user. As with all cryptographic + algorithms, evaluating the necessary strength of the key is important + and dependent on security policy. + + In addition, the usual Diffie-Hellman key strength considerations + apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p + SHOULD be "large", etc. See [RFC 2631, Schneier]. + + + +Copyright, Disclaimer, and Additional IPR Provisions + + Copyright (C) The Internet Society (2006). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Normative References + + [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2434] - "Guidelines for Writing an IANA Considerations Section + in RFCs", T. Narten, H. Alvestrand, October 1998. + + [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June + 1999. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Informative Refences + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, November 1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, November 1987. + + [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. + + [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August + 1999. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley + and Sons. + + + + + + + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 + EMail: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires in September 2006. + + Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +Appendix A: Well known prime/generator pairs + + These numbers are copied from the IPSEC effort where the derivation + of these values is more fully explained and additional information is + available. Richard Schroeppel performed all the mathematical and + computational work for this appendix. + + + +A.1. Well-Known Group 1: A 768 bit prime + + The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its + decimal value is + 155251809230070893513091813125848175563133404943451431320235 + 119490296623994910210725866945387659164244291000768028886422 + 915080371891804634263272761303128298374438082089019628850917 + 0691316593175367469551763119843371637221007210577919 + + Prime modulus: Length (32 bit words): 24, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + +A.2. Well-Known Group 2: A 1024 bit prime + + The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. + Its decimal value is + 179769313486231590770839156793787453197860296048756011706444 + 423684197180216158519368947833795864925541502180565485980503 + 646440548199239100050792877003355816639229553136239076508735 + 759914822574862575007425302077447712589550957937778424442426 + 617334727629299387668709205606050270810842907692932019128194 + 467627007 + + Prime modulus: Length (32 bit words): 32, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 + FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Diffie-Hellman Information in the DNS + + +A.3. Well-Known Group 3: A 1536 bit prime + + The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. + Its decimal value is + 241031242692103258855207602219756607485695054850245994265411 + 694195810883168261222889009385826134161467322714147790401219 + 650364895705058263194273070680500922306273474534107340669624 + 601458936165977404102716924945320037872943417032584377865919 + 814376319377685986952408894019557734611984354530154704374720 + 774996976375008430892633929555996888245787241299381012913029 + 459299994792636526405928464720973038494721168143446471443848 + 8520940127459844288859336526896320919633919 + + Prime modulus Length (32 bit words): 48, Data (hex): + FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 + 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD + EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 + E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED + EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D + C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F + 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D + 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF + + Generator: Length (32 bit words): 1, Data (hex): 2 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt new file mode 100644 index 0000000..8f84fd4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt @@ -0,0 +1,480 @@ + + + + + + +DNSEXT Working Group Paul Vixie, ISC +INTERNET-DRAFT +<draft-ietf-dnsext-rfc2671bis-edns0-01.txt> March 17, 2008 + +Intended Status: Standards Track +Obsoletes: 2671 (if approved) + + + Revised extension mechanisms for DNS (EDNS0) + + +Status of this Memo + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + Abstract + + The Domain Name System's wire protocol includes a number of fixed + fields whose range has been or soon will be exhausted and does not + allow clients to advertise their capabilities to servers. This + document describes backward compatible mechanisms for allowing the + protocol to grow. + + + +Expires September 2008 [Page 1] + +INTERNET-DRAFT EDNS0 March 2008 + + +1 - Introduction + +1.1. DNS (see [RFC1035]) specifies a Message Format and within such +messages there are standard formats for encoding options, errors, and +name compression. The maximum allowable size of a DNS Message is fixed. +Many of DNS's protocol limits are too small for uses which are or which +are desired to become common. There is no way for implementations to +advertise their capabilities. + +1.2. Unextended agents will not know how to interpret the protocol +extensions detailed here. In practice, these clients will be upgraded +when they have need of a new feature, and only new features will make +use of the extensions. Extended agents must be prepared for behaviour +of unextended clients in the face of new protocol elements, and fall +back gracefully to unextended DNS. RFC 2671 originally has proposed +extensions to the basic DNS protocol to overcome these deficiencies. +This memo refines that specification and obsoletes RFC 2671. + +1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", +"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this +document are to be interpreted as described in RFC 2119 [RFC2119]. + +2 - Affected Protocol Elements + +2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit +word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of +1-bit flags. The original reserved Z bits have been allocated to +various purposes, and most of the RCODE values are now in use. More +flags and more possible RCODEs are needed. The OPT pseudo-RR specified +in Section 4 contains subfields that carry a bit field extension of the +RCODE field and additional flag bits, respectively; for details see +Section 4.6 below. + +2.2. The first two bits of a wire format domain label are used to denote +the type of the label. [RFC1035 4.1.4] allocates two of the four +possible types and reserves the other two. Proposals for use of the +remaining types far outnumber those available. More label types were +needed, and an extension mechanism was proposed in RFC 2671 [RFC2671 +Section 3]. Section 3 of this document reserves DNS labels with a first +octet in the range of 64-127 decimal (label type 01) for future +standardization of Extended DNS Labels. + + + + + + + +Expires September 2008 [Page 2] + +INTERNET-DRAFT EDNS0 March 2008 + + +2.3. DNS Messages are limited to 512 octets in size when sent over UDP. +While the minimum maximum reassembly buffer size still allows a limit of +512 octets of UDP payload, most of the hosts now connected to the +Internet are able to reassemble larger datagrams. Some mechanism must +be created to allow requestors to advertise larger buffer sizes to +responders. To this end, the OPT pseudo-RR specified in Section 4 +contains a maximum payload size field; for details see Section 4.5 +below. + +3 - Extended Label Types + +The first octet in the on-the-wire representation of a DNS label +specifies the label type; the basic DNS specification [RFC1035] +dedicates the two most significant bits of that octet for this purpose. + +This document reserves DNS label type 0b01 for use as an indication for +Extended Label Types. A specific extended label type is selected by the +6 least significant bits of the first octet. Thus, Extended Label Types +are indicated by the values 64-127 (0b01xxxxxx) in the first octet of +the label. + +Allocations from this range are to be made for IETF documents fully +describing the syntax and semantics as well as the applicability of the +particular Extended Label Type. + +This document does not describe any specific Extended Label Type. + +4 - OPT pseudo-RR + +4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data +section of a request, and to responses to such requests. An OPT is +called a pseudo-RR because it pertains to a particular transport level +message and not to any actual DNS data. OPT RRs MUST NOT be cached, +forwarded, or stored in or loaded from master files. The quantity of +OPT pseudo-RRs per message MUST be either zero or one, but not greater. + +4.2. An OPT RR has a fixed part and a variable set of options expressed +as {attribute, value} pairs. The fixed part holds some DNS meta data +and also a small collection of new protocol elements which we expect to +be so popular that it would be a waste of wire space to encode them as +{attribute, value} pairs. + + + + + + + +Expires September 2008 [Page 3] + +INTERNET-DRAFT EDNS0 March 2008 + + +4.3. The fixed part of an OPT RR is structured as follows: + +Field Name Field Type Description +------------------------------------------------------ +NAME domain name empty (root domain) +TYPE u_int16_t OPT (41) +CLASS u_int16_t sender's UDP payload size +TTL u_int32_t extended RCODE and flags +RDLEN u_int16_t describes RDATA +RDATA octet stream {attribute,value} pairs + + +4.4. The variable part of an OPT RR is encoded in its RDATA and is +structured as zero or more of the following: + + : +0 (MSB) : +1 (LSB) : + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | OPTION-CODE | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | OPTION-LENGTH | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 4: | | + / OPTION-DATA / + / / + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + +OPTION-CODE (Assigned by IANA.) + +OPTION-LENGTH Size (in octets) of OPTION-DATA. + +OPTION-DATA Varies per OPTION-CODE. + +4.4.1. Order of appearance of option tuples is never relevant. Any +option whose meaning is affected by other options is so affected no +matter which one comes first in the OPT RDATA. + +4.4.2. Any OPTION-CODE values not understood by a responder or requestor +MUST be ignored. So, specifications of such options might wish to +include some kind of signalled acknowledgement. For example, an option +specification might say that if a responder sees option XYZ, it SHOULD +include option XYZ in its response. + + + + + + +Expires September 2008 [Page 4] + +INTERNET-DRAFT EDNS0 March 2008 + + +4.5. The sender's UDP payload size (which OPT stores in the RR CLASS +field) is the number of octets of the largest UDP payload that can be +reassembled and delivered in the sender's network stack. Note that path +MTU, with or without fragmentation, may be smaller than this. Values +lower than 512 are undefined, and may be treated as format errors, or +may be treated as equal to 512, at the implementor's discretion. + +4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP +reassembly buffer. Choosing 1280 on an Ethernet connected requestor +would be reasonable. The consequence of choosing too large a value may +be an ICMP message from an intermediate gateway, or even a silent drop +of the response message. + +4.5.2. Both requestors and responders are advised to take account of the +path's discovered MTU (if already known) when considering message sizes. + +4.5.3. The requestor's maximum payload size can change over time, and +therefore MUST NOT be cached for use beyond the transaction in which it +is advertised. + +4.5.4. The responder's maximum payload size can change over time, but +can be reasonably expected to remain constant between two sequential +transactions; for example, a meaningless QUERY to discover a responder's +maximum UDP payload size, followed immediately by an UPDATE which takes +advantage of this size. (This is considered preferrable to the outright +use of TCP for oversized requests, if there is any reason to suspect +that the responder implements EDNS, and if a request will not fit in the +default 512 payload size limit.) + +4.5.5. Due to transaction overhead, it is unwise to advertise an +architectural limit as a maximum UDP payload size. Just because your +stack can reassemble 64KB datagrams, don't assume that you want to spend +more than about 4KB of state memory per ongoing transaction. + +4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) +are structured as follows: + + : +0 (MSB) : +1 (LSB) : + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: | DO| Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + + + + +Expires September 2008 [Page 5] + +INTERNET-DRAFT EDNS0 March 2008 + + +EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that + EXTENDED-RCODE value zero (0) indicates that an + unextended RCODE is in use (values zero (0) through + fifteen (15)). + +VERSION Indicates the implementation level of whoever sets it. + Full conformance with this specification is indicated by + version zero (0). Requestors are encouraged to set this + to the lowest implemented level capable of expressing a + transaction, to minimize the responder and network load + of discovering the greatest common implementation level + between requestor and responder. A requestor's version + numbering strategy should ideally be a run time + configuration option. + + If a responder does not implement the VERSION level of + the request, then it answers with RCODE=BADVERS. All + responses MUST be limited in format to the VERSION level + of the request, but the VERSION of each response MUST be + the highest implementation level of the responder. In + this way a requestor will learn the implementation level + of a responder as a side effect of every response, + including error responses, including RCODE=BADVERS. + +DO DNSSEC OK bit [RFC3225]. + +Z Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification [IANAFLAGS]. + +5 - Transport Considerations + +5.1. The presence of an OPT pseudo-RR in a request is an indication that +the requestor fully implements the given version of EDNS, and can +correctly understand any response that conforms to that feature's +specification. + +5.2. Lack of use of these features in a request is an indication that +the requestor does not implement any part of this specification and that +the responder SHOULD NOT use any protocol extension described here in +its response. + +5.3. Responders who do not understand these protocol extensions are +expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or +to appear to "time out" due to inappropriate action by a "middle box" +such as a NAT, or to ignore extensions and respond only to unextended + + + +Expires September 2008 [Page 6] + +INTERNET-DRAFT EDNS0 March 2008 + + +protocol elements. Therefore use of extensions SHOULD be "probed" such +that a responder who isn't known to support them be allowed a retry with +no extensions if it responds with such an RCODE, or does not respond. +If a responder's capability level is cached by a requestor, a new probe +SHOULD be sent periodically to test for changes to responder capability. + +5.4. If EDNS is used in a request, and the response arrives with TC set +and with no EDNS OPT RR, a requestor should assume that truncation +prevented the OPT RR from being appended by the responder, and further, +that EDNS is not used in the response. Correspondingly, an EDNS +responder who cannot fit all necessary elements (including an OPT RR) +into a response, should respond with a normal (unextended) DNS response, +possibly setting TC if the response will not fit in the unextended +response message's 512-octet size. + +6 - Security Considerations + +Requestor-side specification of the maximum buffer size may open a new +DNS denial of service attack if responders can be made to send messages +which are too large for intermediate gateways to forward, thus leading +to potential ICMP storms between gateways and responders. + +7 - IANA Considerations + +IANA has allocated RR type code 41 for OPT. + +This document controls the following IANA sub-registries in registry +"DOMAIN NAME SYSTEM PARAMETERS": + + "EDNS Extended Label Type" + "EDNS Option Codes" + "EDNS Version Numbers" + "Domain System Response Code" + +IANA is advised to re-parent these subregistries to this document. + +This document assigns label type 0b01xxxxxx as "EDNS Extended Label +Type." We request that IANA record this assignment. + +This document assigns option code 65535 to "Reserved for future +expansion." + +This document assigns EDNS Extended RCODE "16" to "BADVERS". + + + + + +Expires September 2008 [Page 7] + +INTERNET-DRAFT EDNS0 March 2008 + + +IESG approval is required to create new entries in the EDNS Extended +Label Type or EDNS Version Number registries, while any published RFC +(including Informational, Experimental, or BCP) is grounds for +allocation of an EDNS Option Code. + +8 - Acknowledgements + +Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, +Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten, +Alfred Hoenes and Markku Savela were each instrumental in creating and +refining this specification. + +9 - References + +[RFC1035] P. Mockapetris, "Domain Names - Implementation and + Specification," RFC 1035, USC/Information Sciences + Institute, November 1987. + +[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119, Harvard University, March + 1997. + +[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671, + Internet Software Consortium, August 1999. + +[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC + 3225, Nominum Inc., December 2001. + +[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site + http://www.iana.org/assignments/dns-header-flags, as of + June 2005 or later. + +10 - Author's Address + +Paul Vixie + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 423 1301 + EMail: vixie@isc.org + + + + + + + + +Expires September 2008 [Page 8] + +INTERNET-DRAFT EDNS0 March 2008 + + +Full Copyright Statement + +Copyright (C) IETF Trust (2007). + +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, THE IETF TRUST AND THE +INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + +The IETF takes no position regarding the validity or scope of any +Intellectual Property Rights or other rights that might be claimed to +pertain to the implementation or use of the technology described in this +document or the extent to which any license under such rights might or +might not be available; nor does it represent that it has made any +independent effort to identify any such rights. Information on the +procedures with respect to rights in RFC documents can be found in BCP +78 and BCP 79. + +Copies of IPR disclosures made to the IETF Secretariat and any +assurances of licenses to be made available, or the result of an attempt +made to obtain a general license or permission for the use of such +proprietary rights by implementers or users of this specification can be +obtained from the IETF on-line IPR repository at +http://www.ietf.org/ipr. + +The IETF invites any interested party to bring to its attention any +copyrights, patents or patent applications, or other proprietary rights +that may cover technology that may be required to implement this +standard. Please address the information to the IETF at +ietf-ipr@ietf.org. + +Acknowledgement + +Funding for the RFC Editor function is provided by the IETF +Administrative Support Activity (IASA). + + + + +Expires September 2008 [Page 9] +
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt new file mode 100644 index 0000000..13195bb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-13.txt @@ -0,0 +1,952 @@ + + + +DNS Extensions Working Group S. Rose +Internet-Draft NIST +Obsoletes: 2672 (if approved) W. Wijngaards +Updates: 3363,4294 NLnet Labs +(if approved) May 2, 2008 +Intended status: Standards Track +Expires: November 3, 2008 + + + Update to DNAME Redirection in the DNS + draft-ietf-dnsext-rfc2672bis-dname-13 + +Status of This Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 3, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +Abstract + + The DNAME record provides redirection for a sub-tree of the domain + name tree in the DNS system. That is, all names that end with a + particular suffix are redirected to another part of the DNS. This is + an update of the original specification in RFC 2672, also aligning + RFC 3363 and RFC 4294 with this revision. + + + +Rose & Wijngaards Expires November 3, 2008 [Page 1] + +Internet-Draft DNAME Redirection May 2008 + + +Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 + 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 + 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 6 + 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 + + 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. CNAME synthesis and UD bit . . . . . . . . . . . . . . . . 7 + 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 + 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 + + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10 + + 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 12 + 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 12 + 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12 + 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 12 + 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 12 + 5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12 + 5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 + 5.3.2.2. Valid Name Error Response Involving DNAME in + Bitmap . . . . . . . . . . . . . . . . . . . . . . 13 + 5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 13 + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 2] + +Internet-Draft DNAME Redirection May 2008 + + +1. Introduction + + DNAME is a DNS Resource Record type originally defined in RFC 2672 + [RFC2672]. DNAME provides redirection from a part of the DNS name + tree to another part of the DNS name tree. + + The DNAME RR and the CNAME RR [RFC1034] cause a lookup to + (potentially) return data corresponding to a domain name different + from the queried domain name. The difference between the two + resource records is that the CNAME RR directs the lookup of data at + its owner to another single name, a DNAME RR directs lookups for data + at descendents of its owner's name to corresponding names under a + different (single) node of the tree. + + Take for example, looking through a zone (see RFC 1034 [RFC1034], + section 4.3.2, step 3) for the domain name "foo.example.com" and a + DNAME resource record is found at "example.com" indicating that all + queries under "example.com" be directed to "example.net". The lookup + process will return to step 1 with the new query name of + "foo.example.net". Had the query name been "www.foo.example.com" the + new query name would be "www.foo.example.net". + + This document is an update of the original specification of DNAME in + RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of + maintaining address-to-name mappings in a context of network + renumbering. With a careful set-up, a renumbering event in the + network causes no change to the authoritative server that has the + address-to-name mappings. Examples in practice are classless reverse + address space delegations. + + Another usage of DNAME lies in redirection of name spaces. For + example, a zone administrator may want sub-trees of the DNS to + contain the same information. Examples include punycode alternates + for domain spaces. DNAME is also used for the redirection of ENUM + domains to another maintaining party. + + This update to DNAME does not change the wire format or the handling + of DNAME Resource Records by existing software. A new UD (Understand + DNAME) bit in the EDNS flags field can be used to signal that CNAME + synthesis is not needed. Discussion is added on problems that may be + encountered when using DNAME. + +2. The DNAME Resource Record + +2.1. Format + + The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is + not class-sensitive. + + + +Rose & Wijngaards Expires November 3, 2008 [Page 3] + +Internet-Draft DNAME Redirection May 2008 + + + Its RDATA is comprised of a single field, <target>, which contains a + fully qualified domain name that must be sent in uncompressed form + [RFC1035], [RFC3597]. The <target> field MUST be present. The + presentation format of <target> is that of a domain name [RFC1035]. + + <owner> <ttl> <class> DNAME <target> + + The effect of the DNAME RR is the substitution of the record's + <target> for its owner name, as a suffix of a domain name. This + substitution has to be applied for every DNAME RR found in the + resolution process, which allows fairly lengthy valid chains of DNAME + RRs. + + Details of the substitution process, methods to avoid conflicting + resource records, and rules for specific corner cases are given in + the following subsections. + +2.2. The DNAME Substitution + + When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third + step, "start matching down, label by label, in the zone" and a node + is found to own a DNAME resource record a DNAME substitution occurs. + The name being sought may be the original query name or a name that + is the result of a CNAME resource record being followed or a + previously encountered DNAME. As is the case of finding a CNAME + resource record or NS resource record set, the processing of a DNAME + will happen prior to finding the desired domain name. + + A DNAME substitution is performed by replacing the suffix labels of + the name being sought matching the owner name of the DNAME resource + record with the string of labels in the RDATA field. The matching + labels end with the root label in all cases. Only whole labels are + replaced. See the table of examples for common cases and corner + cases. + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 4] + +Internet-Draft DNAME Redirection May 2008 + + + In the table below, the QNAME refers to the query name. The owner is + the DNAME owner domain name, and the target refers to the target of + the DNAME record. The result is the resulting name after performing + the DNAME substitution on the query name. "no match" means that the + query did not match the DNAME and thus no substitution is performed + and a possible error message is returned (if no other result is + possible). In the examples below, 'cyc' and 'shortloop' contain + loops. + + QNAME owner DNAME target result + ---------------- -------------- -------------- ----------------- + com. example.com. example.net. <no match> + example.com. example.com. example.net. <no match> + a.example.com. example.com. example.net. a.example.net. + a.b.example.com. example.com. example.net. a.b.example.net. + ab.example.com. b.example.com. example.net. <no match> + foo.example.com. example.com. example.net. foo.example.net. + a.x.example.com. x.example.com. example.net. a.example.net. + a.example.com. example.com. y.example.net. a.y.example.net. + cyc.example.com. example.com. example.com. cyc.example.com. + cyc.example.com. example.com. c.example.com. cyc.c.example.com. + shortloop.x.x. x. . shortloop.x. + shortloop.x. x. . shortloop. + + Table 1. DNAME Substitution Examples. + + It is possible for DNAMEs to form loops, just as CNAMEs can form + loops. DNAMEs and CNAMEs can chain together to form loops. A single + corner case DNAME can form a loop. Resolvers and servers should be + cautious in devoting resources to a query, but be aware that fairly + long chains of DNAMEs may be valid. Zone content administrators + should take care to insure that there are no loops that could occur + when using DNAME or DNAME/CNAME redirection. + + The domain name can get too long during substitution. For example, + suppose the target name of the DNAME RR is 250 octets in length + (multiple labels), if an incoming QNAME that has a first label over 5 + octets in length, the result of the result would be a name over 255 + octets. If this occurs the server returns an RCODE of YXDOMAIN + [RFC2136]. The DNAME record and its signature (if the zone is + signed) are included in the answer as proof for the YXDOMAIN (value + 6) RCODE. + +2.3. DNAME Apex not Redirected itself + + Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its + owner name; the owner name of a DNAME is not redirected itself. The + domain name that owns a DNAME record is allowed to have other + + + +Rose & Wijngaards Expires November 3, 2008 [Page 5] + +Internet-Draft DNAME Redirection May 2008 + + + resource record types at that domain name, except DNAMEs or CNAMEs. + This means that DNAME RRs are not allowed at the parent side of a + delegation point but are allowed at a zone apex. + + The reason for this decision was that one can have a DNAME at the + zone apex. There still is a need to have the customary SOA and NS + resource records at the zone apex. This means that DNAME does not + mirror a zone completely, as it does not mirror the zone apex. + + These rules also allow DNAME records to be queried through RFC 1034 + [RFC1034] compliant, DNAME-unaware caches. + +2.4. Names Next to and Below a DNAME Record + + Resource records MUST NOT exist at any domain name subordinate to the + owner of a DNAME RR. To get the contents for names subordinate to + that owner, the DNAME redirection must be invoked and the resulting + target queried. A server MAY refuse to load a zone that has data at + a domain name subordinate to a domain name owning a DNAME RR. If the + server does load the zone, those names below the DNAME RR will be + occluded, RFC 2136 [RFC2136], section 7.18. Also a server SHOULD + refuse to load a zone subordinate to the owner of a DNAME record in + the ancestor zone. See Section 5.2 for further discussion related to + dynamic update. + + DNAME is a singleton type, meaning only one DNAME is allowed per + name. The owner name of a DNAME can only have one DNAME RR, and no + CNAME RRs can exist at that name. These rules make sure that for a + single domain name only one redirection exists, and thus no confusion + which one to follow. A server SHOULD refuse to load a zone that + violates these rules. + +2.5. Compression of the DNAME record. + + The DNAME owner name can be compressed like any other owner name. + The DNAME RDATA target name MUST NOT be sent out in compressed form, + so that a DNAME RR can be treated as an unknown type [RFC3597]. + + Although the previous DNAME specification [RFC2672] (that is + obsoleted by this specification) talked about signaling to allow + compression of the target name, such signaling is not specified. + + RFC 2672 stated that the EDNS version had a meaning for understanding + of DNAME and DNAME target name compression. This document updates + RFC 2672, in that there is no EDNS version signaling for DNAME. + However, the flags section of EDNS(0) is updated with a Understand- + DNAME flag by this document (See Section 3.3). + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 6] + +Internet-Draft DNAME Redirection May 2008 + + +3. Processing + + The DNAME RR causes type NS additional section processing. + +3.1. CNAME synthesis and UD bit + + When preparing an response, a server upon performing a DNAME + substitution will in all cases include the DNAME RR used in the + answer section. A CNAME RR record with TTL equal to the + corresponding DNAME RR is synthesized and included in the answer + section for old resolvers. The owner name of the CNAME is the QNAME + of the query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the + synthesized CNAME does not have to be signed. The DNAME has an RRSIG + and a validating resolver can check the CNAME against the DNAME + record and validate the DNAME record. + + Resolvers MUST be able to handle a synthesized CNAME TTL of zero or + equal to the TTL of the corresponding DNAME record. A TTL of zero + means that the CNAME can be discarded immediately after processing + the answer. DNAME aware resolvers can set the Understand-DNAME (UD + bit) to receive a response with only the DNAME RR and no synthesized + CNAMEs. + + The UD bit is part of the EDNS [RFC2671] extended RCODE and Flags + field. It is used to omit server processing, transmission and + resolver processing of unsigned synthesized CNAMEs. Resolvers can + set this in a query to request omission of the synthesized CNAMEs. + Servers copy the UD bit to the response, and can omit synthesized + CNAMEs from the answer. Older resolvers do not set the UD bit, and + older servers do not copy the UD bit to the answer, and will not omit + synthesized CNAMEs. + + Updated EDNS extended RCODE and Flags field. + + +0 (MSB) +1 (LSB) + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 0: | EXTENDED-RCODE | VERSION | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 2: |DO|UD| Z | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + Servers MUST be able to answer a query for a synthesized CNAME. Like + other query types this invokes the DNAME, and synthesizes the CNAME + into the answer. + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 7] + +Internet-Draft DNAME Redirection May 2008 + + +3.2. Server algorithm + + Below the server algorithm, which appeared in RFC 2672 Section 4.1, + is expanded to handle the UD (Understand DNAME) bit. + + 1. Set or clear the value of recursion available in the response + depending on whether the name server is willing to provide + recursive service. If recursive service is available and + requested via the RD bit in the query, go to step 5, otherwise + step 2. + + 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. + + 3. Start matching down, label by label, in the zone. The matching + process can terminate several ways: + + A. If the whole of QNAME is matched, we have found the node. + + If the data at the node is a CNAME, and QTYPE does not match + CNAME, copy the CNAME RR into the answer section of the + response, change QNAME to the canonical name in the CNAME RR, + and go back to step 1. + + Otherwise, copy all RRs which match QTYPE into the answer + section and go to step 6. + + B. If a match would take us out of the authoritative data, we + have a referral. This happens when we encounter a node with + NS RRs marking cuts along the bottom of a zone. + + Copy the NS RRs for the sub-zone into the authority section + of the reply. Put whatever addresses are available into the + additional section, using glue RRs if the addresses are not + available from authoritative data or the cache. Go to step + 4. + + C. If at some label, a match is impossible (i.e., the + corresponding label does not exist), look to see whether the + last label matched has a DNAME record. + + If a DNAME record exists at that point, copy that record into + the answer section. If substitution of its <target> for its + <owner> in QNAME would overflow the legal size for a <domain- + name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise + perform the substitution and continue. If the EDNS OPT + record is present in the query and the UD bit is set, the + + + +Rose & Wijngaards Expires November 3, 2008 [Page 8] + +Internet-Draft DNAME Redirection May 2008 + + + server MAY copy the UD bit to the answer EDNS OPT record, and + omit CNAME synthesis. Else the server MUST synthesize a + CNAME record as described above and include it in the answer + section. Go back to step 1. + + If there was no DNAME record, look to see if the "*" label + exists. + + 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 or DNAME. 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. If the data at the node with the "*" label 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. Otherwise, Go to step 6. + + 4. Start matching down in the cache. If QNAME is found in the + cache, copy all RRs attached to it that match QTYPE into the + answer section. If QNAME is not found in the cache but a DNAME + record is present at an ancestor of QNAME, copy that DNAME record + into the answer section. If there was no delegation from + authoritative data, look for the best one from the cache, and put + it in the authority section. Go to step 6. + + 5. Use the local resolver or a copy of its algorithm to answer the + query. Store the results, including any intermediate CNAMEs and + DNAMEs, in the answer section of the response. + + 6. Using local data only, attempt to add other RRs which may be + useful to the additional section of the query. Exit. + + Note that there will be at most one ancestor with a DNAME as + described in step 4 unless some zone's data is in violation of the + no-descendants limitation in section 3. An implementation might take + advantage of this limitation by stopping the search of step 3c or + step 4 when a DNAME record is encountered. + +3.3. Wildcards + + The use of DNAME in conjunction with wildcards is discouraged + [RFC4592]. Thus records of the form "*.example.com DNAME + + + +Rose & Wijngaards Expires November 3, 2008 [Page 9] + +Internet-Draft DNAME Redirection May 2008 + + + example.net" SHOULD NOT be used. + + The interaction between the expansion of the wildcard and the + redirection of the DNAME is non-deterministic. Because the + processing is non-deterministic, DNSSEC validating resolvers may not + be able to validate a wildcarded DNAME. + + A server MAY give a warning that the behavior is unspecified if such + a wildcarded DNAME is loaded. The server MAY refuse it, refuse to + load or refuse dynamic update. + +3.4. Acceptance and Intermediate Storage + + DNS caches can encounter data at names below the owner name of a + DNAME RR, due to a change at the authoritative server where data from + before and after the change resides in the cache. This conflict + situation is a transitional phase, that ends when the old data times + out. The cache can opt to store both old and new data and treat each + as if the other did not exist, or drop the old data, or drop the + longer domain name. In any approach, consistency returns after the + older data TTL times out. + + DNS caches MUST perform CNAME synthesis on behalf of DNAME-ignorant + clients. A DNS cache that understands DNAMEs can send out queries on + behalf of clients with the UD bit set (See Section 3.1). After + receiving the answers the DNS cache sends replies to DNAME ignorant + clients that include DNAMEs and synthesized CNAMEs. + +4. DNAME Discussions in Other Documents + + In [RFC2181], in Section 10.3., the discussion on MX and NS records + touches on redirection by CNAMEs, but this also holds for DNAMEs. + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 10] + +Internet-Draft DNAME Redirection May 2008 + + + Excerpt from 10.3. MX and NS records (in RFC 2181). + + The domain name used as the value of a NS resource record, + or part of the value of a MX resource record must not be + an alias. Not only is the specification clear on this + point, but using an alias in either of these positions + neither works as well as might be hoped, nor well fulfills + the ambition that may have led to this approach. This + domain name must have as its value one or more address + records. Currently those will be A records, however in + the future other record types giving addressing + information may be acceptable. It can also have other + RRs, but never a CNAME RR. + + The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. + The opening premise of this section is demonstrably wrong, and so the + conclusion based on that premise is wrong. In particular, [RFC3363] + deprecates the use of DNAME in the IPv6 reverse tree, which is then + carried forward as a recommendation in [RFC4294]. Based on the + experience gained in the meantime, [RFC3363] should be revised, + dropping all constraints on having DNAME RRs in these zones. This + would greatly improve the manageability of the IPv6 reverse tree. + These changes are made explicit below. + + In [RFC3363], the paragraph + + "The issues for DNAME in the reverse mapping tree appears to be + closely tied to the need to use fragmented A6 in the main tree: if + one is necessary, so is the other, and if one isn't necessary, the + other isn't either. Therefore, in moving RFC 2874 to experimental, + the intent of this document is that use of DNAME RRs in the reverse + tree be deprecated." + + is to be replaced with the word "DELETED". + + In [RFC4294], the reference to DNAME was left in as an editorial + oversight. The paragraph + + "Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC3363]." + + is to be replaced by + + "Those nodes are NOT RECOMMENDED to support the experimental + A6 Resource Record [RFC3363]." + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 11] + +Internet-Draft DNAME Redirection May 2008 + + +5. Other Issues with DNAME + + There are several issues to be aware of about the use of DNAME. + +5.1. Canonical hostnames cannot be below DNAME owners + + The names listed as target names of MX, NS, PTR and SRV [RFC2782] + records must be canonical hostnames. This means no CNAME or DNAME + redirection may be present during DNS lookup of the address records + for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, + and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] + page 4. + + The upshot of this is that although the lookup of a PTR record can + involve DNAMEs, the name listed in the PTR record can not fall under + a DNAME. The same holds for NS, SRV and MX records. For example, + when punycode alternates for a zone use DNAME then the NS, MX, SRV + and PTR records that point to that zone must use names without + punycode in their RDATA. What must be done then is to have the + domain names with DNAME substitution already applied to it as the MX, + NS, PTR, SRV data. These are valid canonical hostnames. + +5.2. Dynamic Update and DNAME + + DNAME records can be added, changed and removed in a zone using + dynamic update transactions. Adding a DNAME RR to a zone occludes + any domain names that may exist under the added DNAME. + + A server MUST ignore a dynamic update message that attempts to add a + DNAME RR at a name that already has a CNAME RR or another DNAME RR + associated with that name. + +5.3. DNSSEC and DNAME + +5.3.1. DNAME bit in NSEC type map + + When a validator checks the NSEC RRs returned on a name error + response, it SHOULD check that the DNAME bit is not set. If the + DNAME bit is set then the DNAME substitution should have been done, + but has not. + +5.3.2. Validators Must Understand DNAME + + Examples of why DNSSEC validators MUST understand DNAME. + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 12] + +Internet-Draft DNAME Redirection May 2008 + + +5.3.2.1. DNAME in Bitmap Causes Invalid Name Error + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + foo.bar.example.com. IN A + ;; Answer + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + If this is the response, then only by understanding that the DNAME + bit means that foo.bar.example.com needed to have been redirected by + the DNAME, the validator can see that it is a BOGUS reply from an + attacker that collated existing records from the DNS to create a + confusing reply. + + If the DNAME bit had not been set in the NSEC record above then the + answer would have validated as a correct name error response. + +5.3.2.2. Valid Name Error Response Involving DNAME in Bitmap + + ;; Header: QR AA DO RCODE=3(NXDOMAIN) + ;; Question + cee.example.com. IN A + ;; Answer + bar.example.com. NSEC dub.example.com. A DNAME + bar.example.com. RRSIG NSEC [valid signature] + + This reply has the same NSEC records as the example above, but with + this query name (cee.example.com), the answer is validated, because + 'cee' does not get redirected by the DNAME at 'bar'. + +5.3.2.3. Response With Synthesized CNAME + + ;; Header: QR AA DO RCODE=0(NOERROR) + ;; Question + foo.bar.example.com. IN A + ;; Answer + bar.example.com. DNAME bar.example.net. + bar.example.com. RRSIG DNAME [valid signature] + foo.bar.example.com. CNAME foo.bar.example.net. + + The answer shown above has the synthesized CNAME included. However, + the CNAME has no signature, since the server does not sign online. + So it cannot be trusted. It could be altered by an attacker to be + foo.bar.example.com CNAME bla.bla.example. The DNAME record does + have its signature included, since it does not change for every query + name. The validator must verify the DNAME signature and then + recursively resolve further to query for the foo.bar.example.net A + + + +Rose & Wijngaards Expires November 3, 2008 [Page 13] + +Internet-Draft DNAME Redirection May 2008 + + + record. + +6. IANA Considerations + + The DNAME Resource Record type code 39 (decimal) originally has been + registered by [RFC2672]. IANA should update the DNS resource record + registry to point to this document for RR type 39. + + This draft requests the second highest bit in the EDNS flags field + for the Understand-DNAME (UD) flag. + +7. Security Considerations + + DNAME redirects queries elsewhere, which may impact security based on + policy and the security status of the zone with the DNAME and the + redirection zone's security status. + + If a validating resolver accepts wildcarded DNAMEs, this creates + security issues. Since the processing of a wildcarded DNAME is non- + deterministic and the CNAME that was substituted by the server has no + signature, the resolver may choose a different result than what the + server meant, and consequently end up at the wrong destination. Use + of wildcarded DNAMEs is discouraged in any case [RFC4592]. + + A validating resolver MUST understand DNAME, according to [RFC4034]. + In Section 5.3.2 examples are given that illustrate this need. + +8. Acknowledgments + + The authors of this draft would like to acknowledge Matt Larson for + beginning this effort to address the issues related to the DNAME RR + type. The authors would also like to acknowledge Paul Vixie, Ed + Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred + Hines and Kevin Darcy for their review and comments on this document. + +9. References + +9.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 14] + +Internet-Draft DNAME Redirection May 2008 + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [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. + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + +9.2. Informative References + + [RFC1912] Barr, D., "Common DNS Operational and Configuration + Errors", RFC 1912, February 1996. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, + April 2006. + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 15] + +Internet-Draft DNAME Redirection May 2008 + + +Authors' Addresses + + Scott Rose + NIST + 100 Bureau Dr. + Gaithersburg, MD 20899 + USA + + Phone: +1-301-975-8439 + Fax: +1-301-975-6238 + EMail: scottr@nist.gov + + + Wouter Wijngaards + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + Phone: +31-20-888-4551 + EMail: wouter@nlnetlabs.nl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 16] + +Internet-Draft DNAME Redirection May 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rose & Wijngaards Expires November 3, 2008 [Page 17] + diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt new file mode 100644 index 0000000..0af13c6 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt @@ -0,0 +1,755 @@ + + +Network Working Group B. Laurie +Internet-Draft Nominet +Expires: March 2, 2005 R. Loomis + SAIC + September 2004 + + + + Requirements related to DNSSEC Signed Proof of Non-Existence + draft-ietf-dnsext-signed-nonexistence-requirements-01 + + +Status of this Memo + + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + This Internet-Draft will expire on March 2, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). + + +Abstract + + + DNSSEC-bis uses the NSEC record to provide authenticated denial of + existence of RRsets. NSEC also has the side-effect of permitting + zone enumeration, even if zone transfers have been forbidden. + Because some see this as a problem, this document has been assembled + to detail the possible requirements for denial of existence A/K/A + signed proof of non-existence. + + + + +Laurie & Loomis Expires March 2, 2005 [Page 1] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +Table of Contents + + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4 + 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4 + 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4 + 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5 + 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5 + 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6 + 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6 + 12. Non-overlap of denial records with possible zone records . . 7 + 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7 + 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8 + 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8 + 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8 + 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8 + 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8 + 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8 + 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8 + 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9 + 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9 + 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9 + 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9 + 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9 + 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9 + 29. Security Considerations . . . . . . . . . . . . . . . . . . 10 + 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10 + 30.2 Informative References . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 + Intellectual Property and Copyright Statements . . . . . . . 11 + + + + + + + + + + + + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 2] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +1. Introduction + + + NSEC records allow trivial enumeration of zones - a situation that + has existed for several years but which has recently been raised as a + significant concern for DNSSECbis deployment in several zones. + Alternate proposals have been made that make zone enumeration more + difficult, and some previous proposals to modify DNSSEC had related + requirements/desirements that are relevant to the discussion. In + addition the original designs for NSEC/NXT records were based on + working group discussions and the choices made were not always + documented with context and requirements-- so some of those choices + may need to be restated as requirements. Overall, the working group + needs to better understand the requirements for denial of existence + (and certain other requirements related to DNSSECbis deployment) in + order to evaluate the proposals that may replace NSEC. + + + In the remainder of this document, "NSEC++" is used as shorthand for + "a denial of existence proof that will replace NSEC". "NSECbis" has + also been used as shorthand for this, but we avoid that usage since + NSECbis will not be part of DNSSECbis and therefore there might be + some confusion. + + +2. Non-purposes + + + This document does not currently document the reasons why zone + enumeration might be "bad" from a privacy, security, business, or + other perspective--except insofar as those reasons result in + requirements. Once the list of requirements is complete and vaguely + coherent, the trade-offs (reducing zone enumeration will have X cost, + while providing Y benefit) may be revisited. The editors of this + compendium received inputs on the potential reasons why zone + enumeration is bad (and there was significant discussion on the + DNSEXT WG mailing list) but that information fell outside the scope + of this document. + + + Note also that this document does not assume that NSEC *must* be + replaced with NSEC++, if the requirements can be met through other + methods (e.g., "white lies" with the current NSEC). As is stated + above, this document is focused on requirements collection and + (ideally) prioritization rather than on the actual implementation. + + +3. Zone Enumeration + + + Authenticated denial should not permit trivial zone enumeration. + + + Additional discussion: NSEC (and NXT before it) provide a linked + list that could be "walked" to trivially enumerate all the signed + records in a zone. This requirement is primarily (though not + + + + +Laurie & Loomis Expires March 2, 2005 [Page 3] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + exclusively) important for zones that either are delegation-only/ + -mostly or do not have reverse lookup (PTR) records configured, since + enterprises that have PTR records for all A records have already + provided a similar capability to enumerate the contents of DNS zones. + + + Contributor: various + + +4. Zone Enumeration II + + + Zone enumeration should be at least as difficult as it would be to + effect a dictionary attack using simple DNS queries to do the same in + an unsecured zone. + + + (Editor comment: it is not clear how to measure difficulty in this + case. Some examples could be monetary cost, bandwidth, processing + power or some combination of these. It has also been suggested that + the requirement is that the graph of difficulty of enumeration vs. + the fraction of the zone enumerated should be approximately the same + shape in the two cases) + + + Contributor: Nominet + + +5. Zone Enumeration III + + + Enumeration of a zone with random contents should computationally + infeasible. + + + Editor comment: this is proposed as a way of evaluating the + effectiveness of a proposal rather than as a requirement anyone would + actually have in practice. + + + Contributor: Alex Bligh + + +6. Exposure of Contents + + + NSEC++ should not expose any of the contents of the zone (apart from + the NSEC++ records themselves, of course). + + + Editor comment: this is a weaker requirement than prevention of + enumeration, but certainly any zone that satisfied this requirement + would also satisfy the trivial prevention of enumeration requirement. + + + Contributor: Ed Lewis + + +7. Zone Size + + + Requirement: NSEC++ should make it possible to take precautions + against trivial zone size estimates. Since not all zone owners care + + + + +Laurie & Loomis Expires March 2, 2005 [Page 4] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + about others estimation of the size of a zone, it is not always + necessary to prohibit trivial estimation of the size of the zone but + NSEC++ should allow such measures. + + + Additional Discussion: Even with proposals based on obfuscating names + with hashes it is trivial to give very good estimates of the number + of domains in a certain zone. Just send 10 random queries and look + at the range between the two hash values returned in each NSEC++. As + hash output can be assumed to follow a rectangular random + distribution, using the mean difference between the two values, you + can estimate the total number of records. It is probably sufficient + to look at even one NSEC++, since the two hash values should follow a + (I believe) Poisson distribution. + + + The concern is motivated by some wording remembered from NSEC, which + stated that NSEC MUST only be present for existing owner names in the + zone, and MUST NOT be present for non-existing owner names. If + similar wording were carried over to NSEC++, introducing bogus owner + names in the hash chain (an otherwise simple solution to guard + against trivial estimates of zone size) wouldn't be allowed. + + + One simple attempt at solving this is to describe in the + specifications how zone signer tools can add a number of random + "junk" records. + + + Editor's comment: it is interesting that obfuscating names might + actually make it easier to estimate zone size. + + + Contributor: Simon Josefsson. + + +8. Single Method + + + Requirement: A single NSEC++ method must be able to carry both + old-style denial (i.e. plain labels) and whatever the new style + looks like. Having two separate denial methods could result in + cornercases where one method can deny the other and vice versa. + + + Additional discussion: This requirement can help -bis folks to a + smooth upgrade to -ter. First they'd change the method while the + content is the same, then they can change content of the method. + + + Contributor: Roy Arends. + + +9. Empty Non-terminals + + + Requirement: Empty-non-terminals (ENT) should remain empty. In + other words, adding NSEC++ records to an existing DNS structure + should not cause the creation of NSEC++ records (or related records) + + + + +Laurie & Loomis Expires March 2, 2005 [Page 5] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + at points that are otherwise ENT. + + + Additional discussion: Currently NSEC complies with ENT requirement: + b.example.com NSEC a.c.example.com implies the existence of an ENT + with ownername c.example.com. NSEC2 breaks that requirement, since + the ownername is entirely hashed causing the structure to disappear. + This is why EXIST was introduced. But EXIST causes ENT to be + non-empty-terminals. Next to the dissappearance of ENT, it causes + (some) overhead since an EXIST record needs a SIG, NSEC2 and + SIG(NSEC2). DNSNR honours this requirement by hashing individual + labels instead of ownernames. However this causes very long labels. + Truncation is a measure against very long ownernames, but that is + controversial. There is a fair discussion of the validity of + truncation in the DNSNR draft, but that hasn't got proper review yet. + + + Contributor: Roy Arends. + + + (Editor comment: it is not clear to us that an EXIST record needs an + NSEC2 record, since it is a special purpose record only used for + denial of existence) + + +10. Prevention of Precomputed Dictionary Attacks + + + Requirement: NSEC++ needs to provide a method to reduce the + effectiveness of precomputed dictionary attacks. + + + Additional Discussion: Salt is a measure against dictionary attacks. + There are other possible measures (such as iterating hashes in + NSEC2). The salt needs to be communicated in every response, since + it is needed in every verification. Some have suggested to move the + salt to a special record instead of the denial record. I think this + is not wise. Response size has more priority over zone size. An + extra record causes a larger response than a larger existing record. + + + Contributor: Roy Arends. + + + (Editor comment: the current version of NSEC2 also has the salt in + every NSEC2 record) + + +11. DNSSEC-Adoption and Zone-Growth Relationship + + + Background: Currently with NSEC, when a delegation centric zone + deploys DNSSEC, the zone-size multiplies by a non-trivial factor even + when the DNSSEC-adoption rate of the subzones remains low--because + each delegation point creates at least one NSEC record and + corresponding signature in the parent even if the child is not + signed. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 6] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Requirements: A delegation-only (or delegation-mostly) zone that is + signed but which has no signed child zones should initially need only + to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some + minimal set of NSEC++ records to cover zone contents. Further, + during the transition of a delegation-only zone from 0% signed + children to 100% signed children, the growth in the delegation-only + zone should be roughly proportional to the percentage of signed child + zones. + + + Additional Discussion: This is why DNSNR has the Authoritative Only + bit. This is similar to opt-in for delegations only. This (bit) is + currently the only method to help delegation-centric zone cope with + zone-growth due to DNSSEC adoption. As an example, A delegation only + zone which deploys DNSSEC with the help of this bit, needs to add + SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No + more than that. + + + Contributor: Roy Arends. + + +12. Non-overlap of denial records with possible zone records + + + Requirement: NSEC++ records should in some way be differentiated + from regular zone records, so that there is no possibility that a + record in the zone could be duplicated by a non-existence proof + (NSEC++) record. + + + Additional discussion: This requirement is derived from a discussion + on the DNSEXT mailing list related to copyrights and domain names. + As was outlined there, one solution is to put NSEC++ records in a + separate namespace, e.g.: $ORIGIN co.uk. + 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your + delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345... + ; for amazon.co.uk. + + + Contributor: various + + + (Editor comment: One of us still does not see why a conflict + matters. Even if there is an apparent conflict or overlap, the + "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the + other name _never_ appears in NSEC2 records.) + + +13. Exposure of Private Keys + + + Private keys associated with the public keys in the DNS should be + exposed as little as possible. It is highly undesirable for private + keys to be distributed to nameservers, or to otherwise be available + in the run-time environment of nameservers. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 7] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Contributors: Nominet, Olaf Kolkman, Ed Lewis + + +14. Minimisation of Zone Signing Cost + + + The additional cost of creating an NSEC++ signed zone should not + significantly exceed the cost of creating an ordinary signed zone. + + + Contributor: Nominet + + +15. Minimisation of Asymmetry + + + Nameservers should have to do as little additional work as necessary. + More precisely, it is desirable for any increase in cost incurred by + the nameservers to be offset by a proportionate increase in cost to + DNS `clients', e.g. stub and/or `full-service' resolvers. + + + Contributor: Nominet + + +16. Minimisation of Client Complexity + + + Caching, wildcards, CNAMEs, DNAMEs should continue to work without + adding too much complexity at the client side. + + + Contributor: Olaf Kolkman + + +17. Completeness + + + A proof of nonexistence should be possible for all nonexistent data + in the zone. + + + Contributor: Olaf Kolkman + + +18. Purity of Namespace + + + The name space should not be muddied with fake names or data sets. + + + Contributor: Ed Lewis + + +19. Replay Attacks + + + NSEC++ should not allow a replay to be used to deny existence of an + RR that actually exists. + + + Contributor: Ed Lewis + + +20. Compatibility with NSEC + + + NSEC++ should not introduce changes incompatible with NSEC. + + + + +Laurie & Loomis Expires March 2, 2005 [Page 8] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + Contributor: Ed Lewis + + +21. Compatibility with NSEC II + + + NSEC++ should differ from NSEC in a way that is transparent to the + resolver or validator. + + + Contributor: Ed Lewis + + +22. Compatibility with NSEC III + + + NSEC++ should differ from NSEC as little as possible whilst achieving + other requirements. + + + Contributor: Alex Bligh + + +23. Coexistence with NSEC + + + NSEC++ should be optional, allowing NSEC to be used instead. + + + Contributor: Ed Lewis, Alex Bligh + + +24. Coexistence with NSEC II + + + NSEC++ should not impose extra work on those content with NSEC. + + + Contributor: Ed Lewis + + +25. Protocol Design + + + A good security protocol would allow signing the nonexistence of some + selected names without revealing anything about other names. + + + Contributor: Dan Bernstein + + +26. Process + + + Clearly not all of these requirements can be met. Therefore the next + phase of this document will be to either prioritise them or narrow + them down to a non-contradictory set, which should then allow us to + judge proposals on the basis of their fit. + + +27. Acknowledgements + + +28. Requirements notation + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + + + + +Laurie & Loomis Expires March 2, 2005 [Page 9] +Internet-Draft signed-nonexistence-requirements September 2004 + + + + document are to be interpreted as described in [RFC2119]. + + +29. Security Considerations + + + There are currently no security considerations called out in this + draft. There will be security considerations in the choice of which + requirements will be implemented, but there are no specific security + requirements during the requirements collection process. + + +30. References + + +30.1 Normative References + + + [dnssecbis-protocol] + "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some + Month 2004. + + +30.2 Informative References + + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + + +Authors' Addresses + + + Ben Laurie + Nominet + 17 Perryn Road + London W3 7LR + England + + + Phone: +44 (20) 8735 0686 + EMail: ben@algroup.co.uk + + + + Rip Loomis + Science Applications International Corporation + 7125 Columbia Gateway Drive, Suite 300 + Columbia, MD 21046 + US + + + EMail: gilbert.r.loomis@saic.com + + + + +Laurie & Loomis Expires March 2, 2005 [Page 10] +Internet-Draft signed-nonexistence-requirements September 2004 + + + +Intellectual Property Statement + + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + +Disclaimer of Validity + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Laurie & Loomis Expires March 2, 2005 [Page 11]
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt new file mode 100644 index 0000000..9c73c68 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt @@ -0,0 +1,1292 @@ + + + + + +DNS Extensions Yuji Kamite +Internet-Draft NTT Communications +Expires: April 15, 2005 Masaya Nakayama + The University of Tokyo + October 14, 2004 + + + + TKEY Secret Key Renewal Mode + draft-ietf-dnsext-tkey-renewal-mode-05 + + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 15, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines a new mode in TKEY and proposes an atomic + method for changing secret keys used for TSIG periodically. + Originally, TKEY provides methods of setting up shared secrets other + + + +Kamite, et. al. Expires April 15, 2005 [Page 1] + +INTERNET-DRAFT October 2004 + + + than manual exchange, but it cannot control timing of key renewal + very well though it can add or delete shared keys separately. This + proposal is a systematical key renewal procedure intended for + preventing signing DNS messages with old and non-safe keys + permanently. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4 + 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4 + 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5 + 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5 + 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7 + 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7 + 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7 + 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8 + 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8 + 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10 + 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10 + 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10 + 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11 + 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11 + 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12 + 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13 + 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14 + 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15 + 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15 + 4.2 Authentication Methods Considerations . . . . . . . . . . 15 + 5. Special Considerations for Two Servers' Case . . . . . . . . 16 + 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16 + 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 + 11.2 Informative References . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 23 + + + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 2] + +INTERNET-DRAFT October 2004 + + +1. Introduction + + TSIG [RFC2845] provides DNS message integrity and the + request/transaction authentication by means of message authentication + codes (MAC). TSIG is a practical solution in view of calculation + speed and availability. However, TSIG does not have exchanging + mechanism of shared secret keys between server and resolver, and + administrators might have to exchange secret keys manually. TKEY + [RFC2930] is introduced to solve such problem and it can exchange + secrets for TSIG via networks. + + In various modes of TKEY, a server and a resolver can add or delete a + secret key be means of TKEY message exchange. However, the existing + TKEY does not care fully about the management of keys which became + too old, or dangerous after long time usage. + + It is ideal that the number of secret which a pair of hosts share + should be limited only one, because having too many keys for the same + purpose might not only be a burden to resolvers for managing and + distinguishing according to servers to query, but also does not seem + to be safe in terms of storage and protection against attackers. + Moreover, perhaps holding old keys long time might give attackers + chances to compromise by scrupulous calculation. + + Therefore, when a new shared secret is established by TKEY, the + previous old secret should be revoked immediately. To accomplish + this, DNS servers must support a protocol for key renewal. This + document specifies procedure to refresh secret keys between two hosts + which is defined within the framework of TKEY, and it is called "TKEY + Secret Key Renewal Mode". + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + + +1.1. Defined Words + + * Inception Time: Beginning of the shared secret key lifetime. This + value is determined when the key is generated. + + * Expiry Limit: Time limit of the key's validity. This value is + determined when a new key is generated. After Expiry Limit, server + and client (resolver) must not authenticate TSIG signed with the key. + Therefore, Renewal to the next key should be carried out before + Expiry Limit. + + * Partial Revocation Time: Time when server judges the key is too old + + + +Kamite, et. al. Expires April 15, 2005 [Page 3] + +INTERNET-DRAFT October 2004 + + + and must be updated. It must be between Inception Time and Expiry + Limit. This value is determined by server freely following its + security policy. e.g., If the time from Inception to Partial + Revocation is short, renewal will be carried out more often, which + might be safer. + + * Revocation Time: Time when the key becomes invalid and can be + removed. This value is not determined in advance because it is the + actual time when revocation is completed. + + * Adoption Time: Time when the new key is adopted as the next key + formally. After Adoption, the key is valid and server and client can + generate or verify TSIG making use of it. Adoption Time also means + the time when it becomes possible to remove the previous key, so + Revocation and Adoption are usually done at the same time. + + + Partial + Inception Revocation Revocation Expiry Limit + | | | | + |----------------|- - - - - - >>|- (revoked) -| + | | | | + previous key | | | + |- - - -|-------------------->> time + | | new key + Inception Adoption + + +1.2. New Format and Assigned Numbers + + TSIG + ERROR = (PartialRevoke), TBD + + TKEY + Mode = (server assignment for key renewal), TBD + Mode = (Diffie-Hellman exchange for key renewal), TBD + Mode = (resolver assignment for key renewal), TBD + Mode = (key adoption), TBD + + +1.3. Overview of Secret Key Renewal Mode + + When a server receives a query from a client signed with a TSIG key, + It always checks if the present time is within the range of usage + duration it considers safe. If it is judged that the key is too old, + i.e., after Partial Revocation Time, the server comes to be in + Partial Revocation state about the key, and this key is called + partially revoked. + + + +Kamite, et. al. Expires April 15, 2005 [Page 4] + +INTERNET-DRAFT October 2004 + + + In this state, if a client sends a normal query (e.g., question about + A RR) other than TKEY Renewal request with TSIG signed with the old + key, the server returns an error message to notify that the time to + renew has come. This is called "PartialRevoke" error message. It is + server's choice whether it returns PartialRevoke or not. If and only + if the server is ready for changing its own key, it decides to return + PartialRevoke. + + The client which got this error is able to notice that it is + necessary to refresh the secret. To make a new shared secret, it + sends a TKEY Renewal request, in which several keying methods are + available. It can make use of TSIG authentication signed with the + partially revoked key mentioned above. + + After new secret establishment, the client sends a TKEY Adoption + request for renewal confirmation. This can also be authenticated with + the partially revoked key. If this is admitted by the server, the new + key is formally adopted, and at the same time the corresponding old + secret is invalidated. Then the client can send the first query again + signed with the new key. + + Key renewal procedure is executed based on two-phase commit + mechanism. The first phase is the TKEY Renewal request and its + response, which means preparatory confirmation for key update. The + second phase is Adoption request and its response. If the server gets + request and client receives the response successfully, they can + finish renewal process. If any error happens and renewal process + fails during these phases, client should roll back to the beginning + of the first phase, and send TKEY Renewal request again. This + rollback can be done until the Expiry Limit of the key. + + +2. Shared Secret Key Renewal + + Suppose a server and a client agree to change their TSIG keys + periodically. Key renewal procedure is defined between two hosts. + +2.1. Key Usage Time Check + + Whenever a server receives a query with TSIG and can find a key that + is used for signing it, the server checks its Inception Time, Partial + Revocation Time and Expiry Limit (this information is usually + memorized by the server). + + When the present time is before Inception Time, the server MUST NOT + verify TSIG with the key, and server acts the same way as when the + key used by the client is not recognized. It follows [RFC2845] 4.5.1. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 5] + +INTERNET-DRAFT October 2004 + + + When the present time is equal to Inception Time, or between + Inception Time and Partial Revocation Time, the behavior of the + server is the same as when a valid key is found. It follows [RFC2845] + 4.5.2 and 4.5.3. + + When the present time is the same as the Partial Revocation Time, or + between the Partial Revocation Time and Expiry Limit, the server + comes to be in Partial Revocation state about the TSIG key and + behaves according to the next section. + + When the present time is the same as the Expiry Time or after it, the + server MUST NOT verify TSIG with the key, and returns error messages + in the same way as when the key used by the client is not recognized. + It follows [RFC2845] 4.5.1. + + +2.2. Partial Revocation + + In Partial Revocation state, we say the server has partially revoked + the key and the key has become a "partially revoked key". + + If server has received a query signed with the partially revoked key + for TKEY Renewal request (See section 2.3.) or Key Adoption request + (See section 2.4.), then server does proper process following each + specification. If it is for TKEY key deletion request ([RFC2930] + 4.2), server MAY process usual deletion operation defined therein. + + If server receives other types of query signed with the partially + revoked key, and both the corresponding MAC and signed TIME are + verified, then server begins returning answer whose TSIG error code + is "PartialRevoke" (See section 9.). Server MUST randomly but with + increasing frequency return PartialRevoke when in the Partial + Revocation state. + + Server can decide when it actually sends PartialRevoke, checking if + it is appropriate time for renewal. Server MUST NOT return + PartialRevoke if this is apart long lived TSIG transaction (such as + AXFR) that started before the Partial Revocation Time. + + If the client receives PartialRevoke and understands it, then it MUST + retry the query with the old key unless a new key has been adopted. + Client SHOULD start the process to renew the TSIG key. For key + renewal procedure, see details in Section 2.3 and 2.4. + + PartialRevoke period (i.e., time while server returns PartialRevoke + randomely) SHOULD be small, say 2-5% of key lifetime. This is + server's choice. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 6] + +INTERNET-DRAFT October 2004 + + + Server MUST keep track of clients ignoring PartialRevoke, thus + indicating ignorance of this TKEY mode. + + PartialRevoke error messages have the role to inform clients of the + keys' partial revocation and urge them to send TKEY Renewal requests. + These error responses MUST be signed with those partial revoked keys + if the queries are signed with them. They are sent only when the + signing keys are found to be partially revoked. If the MAC of TSIG + cannot be verified with the partially revoked keys, servers MUST NOT + return PartialRevoke error with MAC, but MUST return another error + such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other + words, a server informs its key's partial revocation only when the + MAC in the received query is valid. + + +2.3. Key Renewal Message Exchange + +2.3.1. Query for Key Renewal + + If a client has received a PartialRevoke error and authenticated the + response based on TSIG MAC, it sends a TKEY query for Key Renewal (in + this document, we call it Renewal request, too.) to the server. The + request MUST be signed with TSIG or SIG(0) [RFC2931] for + authentication. If TSIG is selected, the client can sign it with the + partial revoked key. + + Key Renewal can use one of several keying methods which is indicated + in "Mode" field of TKEY RR, and its message structure is dependent on + that method. + + +2.3.2. Response for Key Renewal + + The server which has received Key Renewal request first tries to + verify TSIG or SIG(0) accompanying it. If the TSIG is signed and + verified with the partially revoked key, the request MUST be + authenticated. + + After authentication, server must check existing old key's validity. + If the partially revoked key indicated in the request TKEY's OldName + and OldAlgorithm field (See section 2.3.4.) does not exist at the + server, "BADKEY" [RFC2845] is given in Error field for response. If + any other error happens, server returns appropriate error messages + following the specification described in section 2.5. If there are no + errors, server returns a Key Renewal answer. This answer MUST be + signed with TSIG or SIG(0) for authentication. + + When this answer is successfully returned and no error is detected by + + + +Kamite, et. al. Expires April 15, 2005 [Page 7] + +INTERNET-DRAFT October 2004 + + + client, a new shared secret can be established. The details of + concrete keying procedure are given in the section 2.5. + + Note: + Sometimes Adoption message and new Renewal request will cross on + the wire. In this case the newly generated key Adoption message is + resent. + + +2.3.3. Attributes of Generated Key + + As a result of this message exchange, client comes to know the newly + generated key's attributes such as key's name, Inception Time and + Expiry Limit. They are decided by the server and told to the client; + in particular, however, once the server has decided Expiry Limit and + returned a response, it should obey the decision as far as it can. In + other words, they SHOULD NOT change time values for checking Expiry + Limit in the future without any special reason, such as security + issue like "Emergency Compulsory Revocation" described in section 8. + + On the other hand, Partial Revocation Time of this generated key is + not decided based on the request, and not informed to the client. The + server can determine any value as long as it is between Inception + Time and Expiry Limit. However, the period from Inception to Partial + Revocation SHOULD be fixed as the server side's configuration or be + set the same as the corresponding old key's one. + + Note: + Even if client sends Key Renewal request though the key described + in OldName has not been partially revoked yet, server does renewal + processes. At the moment when the server accepts such requests + with valid authentication, it MUST forcibly consider the key is + already partially revoked, that is, the key's Partial Revocation + Time must be changed into the present time (i.e., the time when + the server receives the request). + + +2.3.4. TKEY RR structure + + TKEY RR for Key Renewal message has the structure given below. In + principle, format and definition for each field follows [RFC2930]. + Note that each keying scheme sometimes needs different interpretation + of RDATA field; for detail, see section 2.5. + + Field Type Comment + ------- ------ ------- + NAME domain used for a new key, see below + TYPE u_int16_t (defined in [RFC2930]) + + + +Kamite, et. al. Expires April 15, 2005 [Page 8] + +INTERNET-DRAFT October 2004 + + + CLASS u_int16_t (defined in [RFC2930]) + TTL u_int32_t (defined in [RFC2930]) + RDLEN u_int16_t (defined in [RFC2930]) + RDATA: + Algorithm: domain algorithm for a new key + Inception: u_int32_t about the keying material + Expiration: u_int32_t about the keying material + Mode: u_int16_t scheme for key agreement + see section 9. + Error: u_int16_t see description below + Key Size: u_int16_t see description below + Key Data: octet-stream + Other Size: u_int16_t (defined in [RFC2930]) + size of other data + Other Data: newly defined: see description below + + + For "NAME" field, both non-root and root name are allowed. It may + be used for a new key's name in the same manner as [RFC2930] 2.1. + + "Algorithm" specifies which algorithm is used for agreed keying + material, which is used for identification of the next key. + + "Inception" and "Expiration" are used for the valid period of + keying material. The meanings differ somewhat according to whether + the message is request or answer, and its keying scheme. + + "Key Data" has different meanings according to keying schemes. + + "Mode" field stores the value in accordance with the keying method, + and see section 2.5. Servers and clients supporting TKEY Renewal + method MUST implement "Diffie-Hellman exchange for key renewal" + scheme. All other modes are OPTIONAL. + + "Error" is an extended RCODE which includes "PartialRevoke" value + too. See section 9. + + "Other Data" field has the structure given below. They describe + attributes of the key to be renewed. + + in Other Data filed: + + Field Type Comment + ------- ------ ------- + OldNAME domain name of the old key + OldAlgorithm domain algorithm of the old key + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 9] + +INTERNET-DRAFT October 2004 + + + "OldName" indicates the name of the previous key (usually, + this is partially revoked key's name that client noticed by + PartialRevoke answer from server), and "OldAlogirthm" + indicates its algorithm. + + +2.4. Key Adoption + +2.4.1. Query for Key Adoption + + After receiving a TKEY Renewal answer, the client gets the same + secret as the server. Then, it sends a TKEY Adoption request. The + request's question section's QNAME field is the same as the NAME + filed of TKEY written below. In additional section, there is one TKEY + RR that has the structure and values described below. + + "NAME" field is the new key's name to be adopted which was already + generated by Renewal message exchange. "Algorithm" is its + algorithm. "Inception" means the key's Inception Time, and + "Expiration" means Expiry Limit. + + "Mode" field is the value of "key adoption". See section 9. + + "Other Data" field in Adoption has the same structure as that of + Renewal request message. "OldName" means the previous old key, and + "OldAlogirthm" means its algorithm. + + Key Adoption request MUST be signed with TSIG or SIG(0) for + authentication. The client can sign TSIG with the previous key. Note + that until Adoption is finished, the new key is treated as invalid, + thus it cannot be used for authentication immediately. + + +2.4.2. Response for Key Adoption + + The server which has received Adoption request, it verifies TSIG or + SIG(0) accompanying it. If the TSIG is signed with the partially + revoked key and can be verified, the message MUST be authenticated. + + If the next new key indicated by the request TKEY's "NAME" is not + present at the server, BADNAME [RFC2845] is given in Error field and + the error message is returned. + + If the next key exists but it has not been adopted formally yet, the + server confirms the previous key's existence indicated by the + "OldName" and "OldAlgorithm" field. If it succeeds, the server + executes Adoption of the next key and Revocation of the previous key. + Response message duplicates the request's TKEY RR with NOERROR, + + + +Kamite, et. al. Expires April 15, 2005 [Page 10] + +INTERNET-DRAFT October 2004 + + + including "OldName" and "OldAlgorithm" that indicate the revoked key. + + If the next key exists but it is already adopted, the server returns + a response message regardless of the substance of the request TKEY's + "OldName". In this response, Response TKEY RR has the same data as + the request's one except as to its "Other Data" that is changed into + null (i.e., "Other Size" is zero), which is intended for telling the + client that the previous key name was ignored, and the new key is + already available. + + Client sometimes has to retry Adoption request. Suppose the client + sent request signed with the partially revoked key, but its response + did not return successfully (e.g., due to the drop of UDP packet). + Client will probably retry Adoption request; however, the request + will be refused in the form of TSIG "BADKEY" error because the + previous key was already revoked. In this case, client will + retransmit Adoption request signed with the next key, and expect a + response which has null "Other Data" for confirming the completion of + renewal. + + +2.5. Keying Schemes + + In Renewal message exchanges, there are no limitations as to which + keying method is actually used. The specification of keying + algorithms is independent of the general procedure of Renewal that is + described in section 2.3. + + Now this document specifies three algorithms in this section, but + other future documents can make extensions defining other methods. + + +2.5.1. DH Exchange for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.1. This + specification only describes the difference from it and special + notice; assume that all other points, such as keying material + computation, are the exactly same as the specification of [RFC2930] + 4.1. + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + the client's Diffie-Hellman public key [RFC2539]. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 11] + +INTERNET-DRAFT October 2004 + + + TKEY "Mode" field stores the value of "DH exchange for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is used as a random, following [RFC2930] 4.1. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. If + any incompatible DH key is found in the request, "BADKEY" + [RFC2845] is given in Error field for response. "FORMERR" is given + if the query included no DH KEY. + + If there are no errors, the server processes a response according + to Diffie-Hellman algorithm and returns the answer. In this + answer, there is one TKEY RR in answer section and KEY RR(s) in + additional section. + + As long as no error has occurred, all values of TKEY are equal to + that of the request message except TKEY NAME, TKEY RDLEN, RDATA's + Inception, Expiration, Key Size and Key Data. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + TKEY "Key Data" is used as an additional nonce, following + [RFC2930] 4.1. + + The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in + the additional section and a server Diffie-Hellman KEY RR will + also be present in the answer section, following [RFC2930] 4.1. + + +2.5.2. Server Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.4. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.4. + + + +Kamite, et. al. Expires April 15, 2005 [Page 12] + +INTERNET-DRAFT October 2004 + + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. KEY RR is + used in encrypting the response. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "server assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is provided following the specification of + [RFC2930] 4.4. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. + "FORMERR" is given if the query specified no encryption key. + + If there are no errors, the server response contains one TKEY RR + in the answer section, and echoes the KEY RR provided in the query + in the additional information section. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + TKEY "Key Data" is the assigned keying data encrypted under the + public key in the resolver provided KEY RR, which is the same as + [RFC2930] 4.4. + + +2.5.3. Resolver Assigned Keying for Key Renewal + + This scheme is defined as an extended method of [RFC2930] 4.5. This + specification only describes the difference from it and special + notice; assume that all other points, such as secret encrypting + method, are the exactly same as the specification of [RFC2930] 4.5. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 13] + +INTERNET-DRAFT October 2004 + + + Query + In Renewal request for type TKEY with this mode, there is one TKEY + RR and one KEY RR in the additional information section. TKEY RR + has the encrypted keying material and KEY RR is the server public + key used to encrypt the data. + + QNAME in question section is the same as that of "NAME" field in + TKEY RR, i.e., it means the requested new key's name. + + TKEY "Mode" field stores the value of "resolver assignment for key + renewal". See section 9. + + TKEY "Inception" and "Expiration" are those requested for the + keying material, that is, requested usage period of a new key. + + TKEY "Key Data" is the encrypted keying material. + + Response + The server which received this request first verifies the TSIG, + SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the + old key's existence validity is checked, following section 2.3. + "FORMERR" is given if the server does not have the corresponding + private key for the KEY RR that was shown sin the request. + + If there are no errors, the server returns a response. The + response contains a TKEY RR in the answer section to tell the + shared key's name and its usage time values. + + TKEY "NAME" field in the answer specifies the name of newly + produced key which the client MUST use. + + TKEY "Inception" and "Expiration" mean the periods of the produced + key usage. "Inception" is set to be the time when the new key is + actually generated or the time before it, and it will be regarded + as Inception Time. "Expiration" is determined by the server, and + it will be regarded as Expiry Limit. + + +2.6. Considerations about Non-compliant Hosts + + Key Renewal requests and responses must be exchanged between hosts + which can understand them and do proper processes. PartialRevoke + error messages will be only ignored if they should be returned to + non-compliant hosts. + + Note that server does not inform actively the necessity of renewal to + clients, but inform it as responses invoked by client's query. + Server needs not care whether the PartialRevoke errors has reached + + + +Kamite, et. al. Expires April 15, 2005 [Page 14] + +INTERNET-DRAFT October 2004 + + + client or not. If client has not received yet because of any reasons + such as packet drops, it will resend the queries, and finally will be + able to get PartialRevoke information. + + +3. Secret Storage + + Every server keeps all secrets and attached information, e.g., + Inception Time, Expiry Limit, etc. safely to be able to recover from + unexpected stop. To accomplish this, formally adopted keys SHOULD be + memorized not only on memory, but also be stored in the form of some + files. It will become more secure if they are stored in ecrypted + form. + + +4. Compulsory Key Revocation + +4.1. Compulsory Key Revocation by Server + + There is a rare but possible case that although servers have already + partially revoked keys, clients do not try to send any Renewal + requests. If this state continues, in the future it will become the + time of Expiry Limit. After Expiry Limit, the keys will be expired + and completely removed, so this is called Compulsory Key Revocation + by server. + + If Expiry Limit is too distant from the Partial Revocation Time, then + even though very long time passes, clients will be able to refresh + secrets only if they add TSIG signed with those old partially revoked + keys into requests, which is not safe. + + On the other hand, if Expiry Limit is too close to Partial Revocation + Time, perhaps clients might not be able to notice their keys' Partial + Revocation by getting "PartialRevoke" errors. + + Therefore, servers should set proper Expiry Limit to their keys, + considering both their keys' safety, and enough time for clients to + send requests and process renewal. + + +4.2. Authentication Methods Considerations + + It might be ideal to provide both SIG(0) and TSIG as authentication + methods. For example: + + A client and a server start SIG(0) authentication at first, to + establish TSIG shared keys by means of "Query for Diffie-Hellman + Exchanged Keying" as described in [RFC2930] 4.1. Once they get + + + +Kamite, et. al. Expires April 15, 2005 [Page 15] + +INTERNET-DRAFT October 2004 + + + shared secret, they keep using TSIG for queries and responses. + After a while the server returns a "ParitalRevoke" error and they + begin a key renewal process. Both TSIG signed with partially + revoked keys and SIG(0) are okay for authentication, but TSIG would + be easier to use considering calculation efficiency. + + Suppose now client is halted for long time with some reason. + Because server does not execute any renewal process, it will + finally do Compulsory Revocation. Even if client restarts and sends + a key Renewal request, it will fail because old key is already + deleted at server. + + At this moment, however, if client also uses SIG(0) as another + authentication method, it can make a new shared key again and + recover successfully by sending "Query for Diffie-Hellman Exchanged + Keying" with SIG(0). + + +5. Special Considerations for Two servers' Case + + This section refers to the case where both hosts are DNS servers + which can act as full resolvers as well and using one shared key + only. If one server (called Server A) wants to refresh a shared key + (called "Key A-B"), it will await a TKEY Renewal request from the + other server (called Server B). However, perhaps Server A wants to + refresh the key right now. + + In this case, Server A is allowed to send a Renewal request to Server + B, if Server A knows the Key A-B is too old and wants to renew it + immediately. + + Note that the initiative in key renewal belongs to Server A because + it can notice the Partial Revocation Time and decide key renewal. If + Server B has information about Partial Revocation Time as well, it + can also decide for itself to send Renewal request to Server A. + However, it is not essential for both two servers have information + about key renewal timing. + +5.1. To Cope with Collisions of Renewal Requests + + At least one of two hosts which use Key Renewal must know their key + renewal information such as Partial Revocation Time. It is okay that + both hosts have it. + + Provided that both two servers know key renewal timing information, + there is possibility for them to begin partial revocation and sending + Renewal requests to each other at the same time. Such collisions will + not happen so often because Renewal requests are usually invoked when + + + +Kamite, et. al. Expires April 15, 2005 [Page 16] + +INTERNET-DRAFT October 2004 + + + hosts want to send queries, but it is possible. + + When one of two servers tries to send Renewal requests, it MUST + protect old secrets that it has partially revoked and prevent it from + being refreshed by any requests from the other server (i.e., it must + lock the old secret during the process of renewal). While the server + is sending Renewal requests and waiting responses, it ignores the + other server's Renewal requests. + + Therefore, servers might fail to change secrets by means of their own + requests to others. After failure they will try to resend, but they + should wait for random delays by the next retries. If they get any + Renewal requests from others while they are waiting, their shared + keys may be refreshed, then they do not need to send any Renewal + requests now for themselves. + + +6. Key Name Considerations + + Since both servers and clients have only to distinguish new secrets + and old ones, keys' names do not need to be specified strictly. + However, it is recommended that some serial number or key generation + time be added to the name and that the names of keys between the same + pair of hosts should have some common labels among their keys. For + example, suppose A.example.com. and B.example.com. share the key + "<serial number>.A.example.com.B.example.com." such as + "10010.A.example.com.B.example.com.". After key renewal, they change + their secret and name into "10011.A.example.com.B.example.com." + + Servers and clients must be able to use keys properly for each query. + Because TSIG secret keys themselves do not have any particular IDs to + be distinguished and would be identified by their names and + algorithm, it must be understood correctly what keys are refreshed. + + +7. Example Usage of Secret Key Renewal Mode + + This is an example of Renewal mode usage where a Server, + server.example.com, and a Client, client.exmple.com have an initial + shared secret key named "00.client.example.com.server.example.com". + + (1) The time values for key + "00.client.example.com.server.example.com" was set as follows: + Inception Time is at 1:00, Expiry Limit is at 21:00. + + (2) At Server, renewal time has been set: Partial Revocation Time + is at 20:00. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 17] + +INTERNET-DRAFT October 2004 + + + (3) Suppose the present time is 19:55. If Client sends a query + signed with key "00.client.example.com.server.example.com" to ask + the IP address of "www.example.com", finally it will get a proper + answer from Server with valid TSIG (NOERROR). + + (4) At 20:05. Client sends a query to ask the IP address of + "www2.example.com". It is signed with key + "00.client.example.com.server.example.com". Server returns an + answer for the IP address. However, server has begun retuning + PartialRevoke Error randomely. This answer includes valid TSIG MAC + signed with "00.client.example.com.server.example.com", and its + Error Code indicates PartialRevoke. Client understands that the + current key is partially revoked. + + (5) At 20:06. Client sends a Renewal request to Server. This + request is signed with key + "00.client.example.com.server.example.com". It includes data such + as: + + Question Section: + QNAME = 01.client.example.com. (Client can set this freely) + TYPE = TKEY + + Additional Section: + 01.client.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a KEY RR for DH and a TSIG RR. + + (6) As soon as Server receives this request, it verifies TSIG. It + is signed with the partially revoked key + "00.client.example.com.server.example.com". and Server accepts the + request. It creates a new key by Diffie-Hellman calculation and + returns an answer which includes data such as: + + Answer Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (DH exchange for key renewal) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + + +Kamite, et. al. Expires April 15, 2005 [Page 18] + +INTERNET-DRAFT October 2004 + + + Answer Section also contains KEY RRs for DH. + + Additional Section also contains a TSIG RR. + This response is signed with key + "00.client.example.com.server.example.com" without error. + + At the same time, Server decides to set the Partial Revocation Time + of this new key "01.client.example.com.server.example.com." as next + day's 15:00. + + (7) Client gets the response and checks TSIG MAC, and calculates + Diffie-Hellman. It will get a new key, and it has been named + "01.client.example.com.server.example.com" by Server. + + (8) At 20:07. Client sends an Adoption request to Server. This + request is signed with the previous key + "00.client.example.com.server.example.com". It includes: + + Question Section: + QNAME = 01.client.example.com.server.example.com. + TYPE = TKEY + + Additional Section: + 01.client.example.com.server.example.com. TKEY + Algorithm = hmac-md5-sig-alg.reg.int. + Inception = (value meaning 20:00) + Expiration = (value meaning next day's 16:00) + Mode = (key adoption) + OldName = 00.client.example.com.server.example.com. + OldAlgorithm = hmac-md5-sig-alg.reg.int. + + Additional Section also contains a TSIG RR. + + (9) Server verifies the query's TSIG. It is signed with the + previous key and authenticated. It returns a response whose TKEY RR + is the same as the request's one. The response is signed with key + "00.client.example.com.server.example.com.". As soon as the + response is sent, Server revokes and removes the previous key. At + the same time, key "01.client.example.com.server.example.com." is + validated. + + (10) Client acknowledges the success of Adoption by receiving the + response. Then, it retries to send an original question about + "www2.example.com". It is signed with the adopted key + "01.client.example.com.server.example.com", so Server authenticates + it and returns an answer. + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 19] + +INTERNET-DRAFT October 2004 + + + (11) This key is used until next day's 15:00. After that, it will + be partially revoked again. + + +8. Security Considerations + + This document considers about how to refresh shared secret. Secret + changed by this method is used at servers in support of TSIG + [RFC2845]. + + [RFC2104] says that current attacks to HMAC do not indicate a + specific recommended frequency for key changes but periodic key + refreshment is a fundamental security practice that helps against + potential weaknesses of the function and keys, and limits the damage + of an exposed key. TKEY Secret Key Renewal provides the method of + periodical key refreshment. + + In TKEY Secret Key Renewal, clients need to send two requests + (Renewal and Adoption) and spend time to finish their key renewal + processes. Thus the usage period of secrets should be considered + carefully based on both TKEY processing performance and security. + + This document specifies the procedure of periodical key renewal, but + actually there is possibility for servers to have no choice other + than revoking their secret keys immediately especially when the keys + are found to be compromised by attackers. This is called "Emergency + Compulsory Revocation". For example, suppose the original Expiry + Limit was set at 21:00, Partial Revocation Time at 20:00 and + Inception Time at 1:00. if at 11:00 the key is found to be + compromised, the server sets Expiry Limit forcibly to be 11:00 or + before it. + + Consequently, once Compulsory Revocation (See section 4.) is carried + out, normal renewal process described in this document cannot be done + any more as far as the key is concerned. However, after such + accidents happened, the two hosts are able to establish secret keys + and begin renewal procedure only if they have other (non-compromised) + shared TSIG keys or safe SIG(0) keys for the authentication of + initial secret establishment such as Diffie-Hellman Exchanged Keying. + + +9. IANA Considerations + + IANA needs to allocate a value for "DH exchange for key renewal", + "server assignment for key renewal", "resolver assignment for key + renewal" and "key adoption" in the mode filed of TKEY. It also needs + to allocate a value for "PartialRevoke" from the extended RCODE + space. + + + +Kamite, et. al. Expires April 15, 2005 [Page 20] + +INTERNET-DRAFT October 2004 + + +10. Acknowledgements + + The authors would like to thank Olafur Gudmundsson, whose helpful + input and comments contributed greatly to this document. + + +11. References + +11.1. Normative References + +[RFC2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + +[RFC2539] + D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name + System (DNS)", RFC 2539, March 1999. + +[RFC2845] + Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, + May 2000. + +[RFC2930] + D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', + RFC 2930, September 2000. + +[RFC2931] + D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s + )", RFC 2931, September 2000. + +11.2. Informative References + +[RFC2104] + H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message + Authentication", RFC2104, February 1997. + + + + + + + + + + + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 21] + +INTERNET-DRAFT October 2004 + + +Authors' Addresses + + Yuji Kamite + NTT Communications Corporation + Tokyo Opera City Tower + 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo + 163-1421, Japan + EMail: y.kamite@ntt.com + + + Masaya Nakayama + Information Technology Center, The University of Tokyo + 2-11-16 Yayoi, Bunkyo-ku, Tokyo + 113-8658, Japan + EMail: nakayama@nc.u-tokyo.ac.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kamite, et. al. Expires April 15, 2005 [Page 22] + +INTERNET-DRAFT October 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Kamite, et. al. Expires April 15, 2005 [Page 23] + + + diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt new file mode 100644 index 0000000..eaf6865 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt @@ -0,0 +1,1501 @@ +Network Working Group J. Ihren +Internet-Draft Autonomica AB +Expires: April 18, 2005 O. Kolkman + RIPE NCC + B. Manning + EP.net + October 18, 2004 + + + + An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for + DNSSEC Trust Anchors. + draft-ietf-dnsext-trustupdate-threshold-00 + + +Status of this Memo + + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + This Internet-Draft will expire on April 18, 2005. + + +Copyright Notice + + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + + The DNS Security Extensions (DNSSEC) works by validating so called + chains of authority. The start of these chains of authority are + usually public keys that are anchored in the DNS clients. These keys + are known as the so called trust anchors. + + + + + +Ihren, et al. Expires April 18, 2005 [Page 1] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + This memo describes a method how these client trust anchors can be + replaced using the DNS validation and querying mechanisms (in-band) + when the key pairs used for signing by zone owner are rolled. + + + This memo also describes a method to establish the validity of trust + anchors for initial configuration, or priming, using out of band + mechanisms. + + +Table of Contents + + + 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry + Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Introduction and Background . . . . . . . . . . . . . . . . . 5 + 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5 + 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7 + 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8 + 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9 + 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10 + 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11 + 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12 + 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12 + 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12 + 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12 + 3.6 Removal of trust anchors for a trust point . . . . . . . . 12 + 3.7 No need for resolver-side overlap of old and new keys . . 13 + 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14 + 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.1.1 Bootstrapping trust anchors using a priming key . . . 14 + 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15 + 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 6.1 Threshold-based Trust Update Security Considerations . . . 17 + 6.2 Priming Key Security Considerations . . . . . . . . . . . 17 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 + 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 + A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23 + B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23 + B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . . 24 + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 2] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +1. Terminology + + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC2119 [1]. + + + The term "zone" refers to the unit of administrative control in the + Domain Name System. In this document "name server" denotes a DNS + name server that is authoritative (i.e. knows all there is to know) + for a DNS zone. A "zone owner" is the entity responsible for signing + and publishing a zone on a name server. The terms "authentication + chain", "bogus", "trust anchors" and "Island of Security" are defined + in [4]. Throughout this document we use the term "resolver" to mean + "Validating Stub Resolvers" as defined in [4]. + + + We use the term "security apex" as the zone for which a trust anchor + has been configured (by validating clients) and which is therefore, + by definition, at the root of an island of security. The + configuration of trust anchors is a client side issue. Therefore a + zone owner may not always know if their zone has become a security + apex. + + + A "stale anchor" is a trust anchor (a public key) that relates to a + key that is not used for signing. Since trust anchors indicate that + a zone is supposed to be secure a validator will mark the all data in + an island of security as bogus when all trust anchors become stale. + + + It is assumed that the reader is familiar with public key + cryptography concepts [REF: Schneier Applied Cryptography] and is + able to distinguish between the private and public parts of a key + based on the context in which we use the term "key". If there is a + possible ambiguity we will explicitly mention if a private or a + public part of a key is used. + + + The term "administrator" is used loosely throughout the text. In + some cases an administrator is meant to be a person, in other cases + the administrator may be a process that has been delegated certain + responsibilities. + + +1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points + + + Although the DNSSEC protocol does not make a distinction between + different keys the operational practice is that a distinction is made + between zone signing keys and key signing keys. A key signing key is + used to exclusively sign the DNSKEY Resource Record (RR) set at the + apex of a zone and the zone signing keys sign all the data in the + zone (including the DNSKEY RRset at the apex). + + + + + +Ihren, et al. Expires April 18, 2005 [Page 3] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + Keys that are intended to be used as the start of the authentication + chain for a particular zone, either because they are pointed to by a + parental DS RR or because they are configured as a trust anchor, are + called Secure Entry Point (SEP) keys. In practice these SEP keys + will be key signing keys. + + + In order for the mechanism described herein to work the keys that are + intended to be used as secure entry points MUST have the SEP [2] flag + set. In the examples it is assumed that keys with the SEP flag set + are used as key signing keys and thus exclusively sign the DNSKEY + RRset published at the apex of the zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 4] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +2. Introduction and Background + + + When DNSSEC signatures are validated the resolver constructs a chain + of authority from a pre-configured trust anchor to the DNSKEY + Resource Record (RR), which contains the public key that validates + the signature stored in an RRSIG RR. DNSSEC is designed so that the + administrator of a resolver can validate data in multiple islands of + security by configuring multiple trust anchors. + + + It is expected that resolvers will have more than one trust anchor + configured. Although there is no deployment experience it is not + unreasonable to expect resolvers to be configured with a number of + trust anchors that varies between order 1 and order 1000. Because + zone owners are expected to roll their keys, trust anchors will have + to be maintained (in the resolver end) in order not to become stale. + + + Since there is no global key maintenance policy for zone owners and + there are no mechanisms in the DNS to signal the key maintenance + policy it may be very hard for resolvers administrators to keep their + set of trust anchors up to date. For instance, if there is only one + trust anchor configured and the key maintenance policy is clearly + published, through some out of band trusted channel, then a resolver + administrator can probably keep track of key rollovers and update the + trust anchor manually. However, with an increasing number of trust + anchors all rolled according to individual policies that are all + published through different channels this soon becomes an + unmanageable problem. + + +2.1 Dangers of Stale Trust Anchors + + + Whenever a SEP key at a security apex is rolled there exists a danger + that "stale anchors" are created. A stale anchor is a trust anchor + (i.e. a public key configured in a validating resolver) that relates + to a private key that is no longer used for signing. + + + The problem with a stale anchors is that they will (from the + validating resolvers point of view) prove data to be false even + though it is actually correct. This is because the data is either + signed by a new key or is no longer signed and the resolver expects + data to be signed by the old (now stale) key. + + + This situation is arguably worse than not having a trusted key + configured for the secure entry point, since with a stale key no + lookup is typically possible (presuming that the default + configuration of a validating recursive nameserver is to not give out + data that is signed but failed to verify. + + + The danger of making configured trust anchors become stale anchors + + + + +Ihren, et al. Expires April 18, 2005 [Page 5] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + may be a reason for zone owners not to roll their keys. If a + resolver is configured with many trust anchors that need manual + maintenance it may be easy to not notice a key rollover at a security + apex, resulting in a stale anchor. + + + In Section 3 this memo sets out a lightweight, in-DNS, mechanism to + track key rollovers and modify the configured trust anchors + accordingly. The mechanism is stateless and does not need protocol + extensions. The proposed design is that this mechanism is + implemented as a "trust updating machine" that is run entirely + separate from the validating resolver except that the trust updater + will have influence over the trust anchors used by the latter. + + + In Section 4 we describe a method [Editors note: for now only the + frame work and a set of requirements] to install trust anchors. This + method can be used at first configuration or when the trust anchors + became stale (typically due to a failure to track several rollover + events). + + + The choice for which domains trust anchors are to be configured is a + local policy issue. So is the choice which trust anchors has + prevalence if there are multiple chains of trust to a given piece of + DNS data (e.g. when a parent zone and its child both have trust + anchors configured). Both issues are out of the scope of this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 6] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +3. Threshold-based Trust Anchor Rollover + + +3.1 The Rollover + + + When a key pair is replaced all signatures (in DNSSEC these are the + RRSIG records) created with the old key will be replaced by new + signatures created by the new key. Access to the new public key is + needed to verify these signatures. + + + Since zone signing keys are in "the middle" of a chain of authority + they can be verified using the signature made by a key signing key. + Rollover of zone signing keys is therefore transparent to validators + and requires no action in the validator end. + + + But if a key signing key is rolled a resolver can determine its + authenticity by either following the authorization chain from the + parents DS record, an out-of-DNS authentication mechanism or by + relying on other trust anchors known for the zone in which the key is + rolled. + + + The threshold trust anchor rollover mechanism (or trust update), + described below, is based on using existing trust anchors to verify a + subset of the available signatures. This is then used as the basis + for a decision to accept the new keys as valid trust anchors. + + + Our example pseudo zone below contains a number of key signing keys + numbered 1 through Y and two zone signing keys A and B. During a key + rollover key 2 is replaced by key Y+1. The zone content changes + from: + + + example.com. DNSKEY key1 + example.com. DNSKEY key2 + example.com. DNSKEY key3 + ... + example.com. DNSKEY keyY + + + example.com. DNSKEY keyA + example.com. DNSKEY keyB + + + example.com. RRSIG DNSKEY ... (key1) + example.com. RRSIG DNSKEY ... (key2) + example.com. RRSIG DNSKEY ... (key3) + ... + example.com. RRSIG DNSKEY ... (keyY) + example.com. RRSIG DNSKEY ... (keyA) + example.com. RRSIG DNSKEY ... (keyB) + + + to: + + + + +Ihren, et al. Expires April 18, 2005 [Page 7] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + example.com. DNSKEY key1 + example.com. DNSKEY key3 + ... + example.com. DNSKEY keyY + example.com. DNSKEY keyY+1 + + + example.com. RRSIG DNSKEY ... (key1) + example.com. RRSIG DNSKEY ... (key3) + ... + example.com. RRSIG DNSKEY ... (keyY) + example.com. RRSIG DNSKEY ... (keyY+1) + example.com. RRSIG DNSKEY ... (keyA) + example.com. RRSIG DNSKEY ... (keyB) + + + When the rollover becomes visible to the verifying stub resolver it + will be able to verify the RRSIGs associated with key1, key3 ... + keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will + not be used for validation, since that key is previously unknown and + therefore not trusted. + + + Note that this example is simplified. Because of operational + considerations described in [5] having a period during which the two + key signing keys are both available is necessary. + + +3.2 Threshold-based Trust Update + + + The threshold-based trust update algorithm applies as follows. If + for a particular secure entry point + o if the DNSKEY RRset in the zone has been replaced by a more recent + one (as determined by comparing the RRSIG inception dates) + and + o if at least M configured trust anchors directly verify the related + RRSIGs over the new DNSKEY RRset + and + o the number of configured trust anchors that verify the related + RRSIGs over the new DNSKEY RRset exceed a locally defined minimum + number that should be greater than one + then all the trust anchors for the particular secure entry point are + replaced by the set of keys from the zones DNSKEY RRset that have the + SEP flag set. + + + The choices for the rollover acceptance policy parameter M is left to + the administrator of the resolver. To be certain that a rollover is + accepted up by resolvers using this mechanism zone owners should roll + as few SEP keys at a time as possible (preferably just one). That + way they comply to the most strict rollover acceptance policy of + M=N-1. + + + + + +Ihren, et al. Expires April 18, 2005 [Page 8] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + The value of M has an upper bound, limited by the number of of SEP + keys a zone owner publishes (i.e. N). But there is also a lower + bound, since it will not be safe to base the trust in too few + signatures. The corner case is M=1 when any validating RRSIG will be + sufficient for a complete replacement of the trust anchors for that + secure entry point. This is not a recommended configuration, since + that will allow an attacker to initiate rollover of the trust anchors + himself given access to just one compromised key. Hence M should in + be strictly larger than 1 as shown by the third requirement above. + + + If the rollover acceptance policy is M=1 then the result for the + rollover in our example above should be that the local database of + trust anchors is updated by removing key "key2" from and adding key + "keyY+1" to the key store. + + +3.3 Possible Trust Update States + + + We define five states for trust anchor configuration at the client + side. + PRIMING: There are no trust anchors configured. There may be priming + keys available for initial priming of trust anchors. + IN-SYNC: The set of trust anchors configured exactly matches the set + of SEP keys used by the zone owner to sign the zone. + OUT-OF-SYNC: The set of trust anchors is not exactly the same as the + set of SEP keys used by the zone owner to sign the zone but there + are enough SEP key in use by the zone owner that is also in the + trust anchor configuration. + UNSYNCABLE: There is not enough overlap between the configured trust + anchors and the set of SEP keys used to sign the zone for the new + set to be accepted by the validator (i.e. the number of + signatures that verify is not sufficient). + STALE: There is no overlap between the configured trust anchors and + the set of SEP keys used to sign the zone. Here validation of + data is no longer possible and hence we are in a situation where + the trust anchors are stale. + + + Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of + the automatic trust update mechanism. The PRIMING state is where a + validator is located before acquiring an up-to-date set of trust + anchors. The transition from PRIMING to IN-SYNC is manual (see + Section 4 below). + + + Example: assume a secure entry point with four SEP keys and a + validator with the policy that it will accept any update to the set + of trust anchors as long as no more than two signatures fail to + validate (i.e. M >= N-2) and at least two signature does validate + (i.e. M >= 2). In this case the rollover of a single key will move + the validator from IN-SYNC to OUT-OF-SYNC. When the trust update + + + + +Ihren, et al. Expires April 18, 2005 [Page 9] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + state machine updates the trust anchors it returns to state IN-SYNC. + + + If if for some reason it fails to update the trust anchors then the + next rollover (of a different key) will move the validator from + OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys + that are configured as trust anchors and that is sufficient to accpt + an automatic update of the trust anchors. + + + The UNSYNCABLE state is where a validator is located if it for some + reason fails to incorporate enough updates to the trust anchors to be + able to accept new updates according to its local policy. In this + example (i.e. with the policy specified above) this will either be + because M < N-2 or M < 2, which does not suffice to authenticate a + successful update of trust anchors. + + + Continuing with the previous example where two of the four SEP keys + have already rolled, but the validator has failed to update the set + of trust anchors. When the third key rolls over there will only be + one trust anchor left that can do successful validation. This is not + sufficient to enable automatic update of the trust anchors, hence the + new state is UNSYNCABLE. Note, however, that the remaining + up-to-date trust anchor is still enough to do successful validation + so the validator is still "working" from a DNSSEC point of view. + + + The STALE state, finally, is where a validator ends up when it has + zero remaining current trust anchors. This is a dangerous state, + since the stale trust anchors will cause all validation to fail. The + escape is to remove the stale trust anchors and thereby revert to the + PRIMING state. + + +3.4 Implementation notes + + + The DNSSEC protocol specification ordains that a DNSKEY to which a DS + record points should be self-signed. Since the keys that serve as + trust anchors and the keys that are pointed to by DS records serve + the same purpose, they are both secure entry points, we RECOMMEND + that zone owners who want to facilitate the automated rollover scheme + documented herein self-sign DNSKEYs with the SEP bit set and that + implementation check that DNSKEYs with the SEP bit set are + self-signed. + + + In order to maintain a uniform way of determining that a keyset in + the zone has been replaced by a more recent set the automatic trust + update machine SHOULD only accept new DNSKEY RRsets if the + accompanying RRSIGs show a more recent inception date than the + present set of trust anchors. This is also needed as a safe guard + against possible replay attacks where old updates are replayed + "backwards" (i.e. one change at a time, but going in the wrong + + + + +Ihren, et al. Expires April 18, 2005 [Page 10] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + direction, thereby luring the validator into the UNSYNCABLE and + finally STALE states). + + + In order to be resilient against failures the implementation should + collect the DNSKEY RRsets from (other) authoritative servers if + verification of the self signatures fails. + + + The threshold-based trust update mechanism SHOULD only be applied to + algorithms, as represented in the algorithm field in the DNSKEY/RRSIG + [3], that the resolver is aware of. In other words the SEP keys of + unknown algorithms should not be used when counting the number of + available signatures (the N constant) and the SEP keys of unknown + algorithm should not be entered as trust anchors. + + + When in state UNSYNCABLE or STALE manual intervention will be needed + to return to the IN-SYNC state. These states should be flagged. The + most appropriate action is human audit possibly followed by + re-priming (Section 4) the keyset (i.e. manual transfer to the + PRIMING state through removal of the configured trust anchors). + + + An implementation should regularly probe the the authoritative + nameservers for new keys. Since there is no mechanism to publish + rollover frequencies this document RECOMMENDS zone owners not to roll + their key signing keys more often than once per month and resolver + administrators to probe for key rollsovers (and apply the threshold + criterion for acceptance of trust update) not less often than once + per month. If the rollover frequency is higher than the probing + frequency then trust anchors may become stale. The exact relation + between the frequencies depends on the number of SEP keys rolled by + the zone owner and the value M configured by the resolver + administrator. + + + In all the cases below a transaction where the threshold criterion is + not satisfied should be considered bad (i.e. possibly spoofed or + otherwise corrupted data). The most appropriate action is human + audit. + + + There is one case where a "bad" state may be escaped from in an + automated fashion. This is when entering the STALE state where all + DNSSEC validation starts to fail. If this happens it is concievable + that it is better to completely discard the stale trust anchors + (thereby reverting to the PRIMING state where validation is not + possible). A local policy that automates removal of stale trust + anchors is therefore suggested. + + +3.5 Possible transactions + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 11] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +3.5.1 Single DNSKEY replaced + + + This is probably the most typical transaction on the zone owners + part. The result should be that if the threshold criterion is + satisfied then the key store is updated by removal of the old trust + anchor and addition of the new key as a new trust anchor. Note that + if the DNSKEY RRset contains exactly M keys replacement of keys is + not possible, i.e. for automatic rollover to work M must be stricly + less than N. + + +3.5.2 Addition of a new DNSKEY (no removal) + + + If the threshold criterion is satisfied then the new key is added as + a configured trust anchor. Not more than N-M keys can be added at + once, since otherwise the algorithm will fail. + + +3.5.3 Removal of old DNSKEY (no addition) + + + If the threshold criterion is satisfied then the old key is removed + from being a configured trust anchor. Note that it is not possible + to reduce the size of the DNSKEY RRset to a size smaller than the + minimum required value for M. + + +3.5.4 Multiple DNSKEYs replaced + + + Arguably it is not a good idea for the zone administrator to replace + several keys at the same time, but from the resolver point of view + this is exactly what will happen if the validating resolver for some + reason failed to notice a previous rollover event. + + + Not more than N-M keys can be replaced at one time or the threshold + criterion will not be satisfied. Or, expressed another way: as long + as the number of changed keys is less than or equal to N-M the + validator is in state OUT-OF-SYNC. When the number of changed keys + becomes greater than N-M the state changes to UNSYNCABLE and manual + action is needed. + + +3.6 Removal of trust anchors for a trust point + + + If the parent of a secure entry point gets signed and it's trusted + keys get configured in the key store of the validating resolver then + the configured trust anchors for the child should be removed entirely + unless explicitly configured (in the utility configuration) to be an + exception. + + + The reason for such a configuration would be that the resolver has a + local policy that requires maintenance of trusted keys further down + the tree hierarchy than strictly needed from the point of view. + + + + +Ihren, et al. Expires April 18, 2005 [Page 12] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + The default action when the parent zone changes from unsigned to + signed should be to remove the configured trust anchors for the + child. This form of "garbage collect" will ensure that the automatic + rollover machinery scales as DNSSEC deployment progresses. + + +3.7 No need for resolver-side overlap of old and new keys + + + It is worth pointing out that there is no need for the resolver to + keep state about old keys versus new keys, beyond the requirement of + tracking signature inception time for the covering RRSIGs as + described in Section 3.4. + + + From the resolver point of view there are only trusted and not + trusted keys. The reason is that the zone owner needs to do proper + maintenance of RRSIGs regardless of the resolver rollover mechanism + and hence must ensure that no key rolled out out the DNSKEY set until + there cannot be any RRSIGs created by this key still legally cached. + + + Hence the rollover mechanism is entirely stateless with regard to the + keys involved: as soon as the resolver (or in this case the rollover + tracking utility) detects a change in the DNSKEY RRset (i.e. it is + now in the state OUT-OF-SYNC) with a sufficient number of matching + RRSIGs the configured trust anchors are immediately updated (and + thereby the machine return to state IN-SYNC). I.e. the rollover + machine changes states (mostly oscillating between IN-SYNC and + OUT-OF-SYNC), but the status of the DNSSEC keys is stateless. + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 13] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +4. Bootstrapping automatic rollovers + + + It is expected that with the ability to automatically roll trust + anchors at trust points will follow a diminished unwillingness to + roll these keys, since the risks associated with stale keys are + minimized. + + + The problem of "priming" the trust anchors, or bringing them into + sync (which could happen if a resolver is off line for a long period + in which a set of SEP keys in a zone 'evolve' away from its trust + anchor configuration) remains. + + + For (re)priming we can rely on out of band technology and we propose + the following framework. + + +4.1 Priming Keys + + + If all the trust anchors roll somewhat frequently (on the order of + months or at most about a year) then it will not be possible to + design a device, or a software distribution that includes trust + anchors, that after being manufactured is put on a shelf for several + key rollover periods before being brought into use (since no trust + anchors that were known at the time of manufacture remain active). + + + To alleviate this we propose the concept of "priming keys". Priming + keys are ordinary DNSSEC Key Signing Keys with the characteristic + that + o The private part of a priming key signs the DNSKEY RRset at the + security apex, i.e. at least one RRSIG DNSKEY is created by a + priming key rather than by an "ordinary" trust anchor + o the public parts of priming keys are not included in the DNSKEY + RRset. Instead the public parts of priming keys are only + available out-of-band. + o The public parts of the priming keys have a validity period. + Within this period they can be used to obtain trust anchors. + o The priming key pairs are long lived (relative to the key rollover + period.) + + +4.1.1 Bootstrapping trust anchors using a priming key + + + To install the trust anchors for a particular security apex an + administrator of a validating resolver will need to: + o query for the DNSKEY RRset of the zone at the security apex; + o verify the self signatures of all DNSKEYs in the RRset; + o verify the signature of the RRSIG made with a priming key -- + verification using one of the public priming keys that is valid at + that moment is sufficient; + + + + + +Ihren, et al. Expires April 18, 2005 [Page 14] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + o create the trust anchors by extracting the DNSKEY RRs with the SEP + flag set. + The SEP keys with algorithms unknown to the validating resolver + SHOULD be ignored during the creation of the trust anchors. + + +4.1.2 Distribution of priming keys + + + The public parts of the priming keys SHOULD be distributed + exclusively through out-of-DNS mechanisms. The requirements for a + distribution mechanism are: + o it can carry the "validity" period for the priming keys; + o it can carry the self-signature of the priming keys; + o and it allows for verification using trust relations outside the + DNS. + A distribution mechanism would benefit from: + o the availability of revocation lists; + o the ability of carrying zone owners policy information such as + recommended values for "M" and "N" and a rollover frequency; + o and the technology on which is based is readily available. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 15] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +5. The Threshold Rollover Mechanism vs Priming + + + There is overlap between the threshold-based trust updater and the + Priming method. One could exclusively use the Priming method for + maintaining the trust anchors. However the priming method probably + relies on "non-DNS' technology and may therefore not be available for + all devices that have a resolver. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 16] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +6. Security Considerations + + +6.1 Threshold-based Trust Update Security Considerations + + + A clear issue for resolvers will be how to ensure that they track all + rollover events for the zones they have configure trust anchors for. + Because of temporary outages validating resolvers may have missed a + rollover of a KSK. The parameters that determine the robustness + against failures are: the length of the period between rollovers + during which the KSK set is stable and validating resolvers can + actually notice the change; the number of available KSKs (i.e. N) + and the number of signatures that may fail to validate (i.e. N-M). + + + With a large N (i.e. many KSKs) and a small value of M this + operation becomes more robust since losing one key, for whatever + reason, will not be crucial. Unfortunately the choice for the number + of KSKs is a local policy issue for the zone owner while the choice + for the parameter M is a local policy issue for the resolver + administrator. + + + Higher values of M increase the resilience against attacks somewhat; + more signatures need to verify for a rollover to be approved. On the + other hand the number of rollover events that may pass unnoticed + before the resolver reaches the UNSYNCABLE state goes down. + + + The threshold-based trust update intentionally does not provide a + revocation mechanism. In the case that a sufficient number of + private keys of a zone owner are simultaneously compromised the the + attacker may use these private keys to roll the trust anchors of (a + subset of) the resolvers. This is obviously a bad situation but it + is not different from most other public keys systems. + + + However, it is important to point out that since any reasonable trust + anchor rollover policy (in validating resolvers) will require more + than one RRSIG to validate this proposal does provide security + concious zone administrators with the option of not storing the + individual private keys in the same location and thereby decreasing + the likelihood of simultaneous compromise. + + +6.2 Priming Key Security Considerations + + + Since priming keys are not included in the DNSKEY RR set they are + less sensitive to packet size constraints and can be chosen + relatively large. The private parts are only needed to sign the + DNSKEY RR set during the validity period of the particular priming + key pair. Note that the private part of the priming key is used each + time when a DNSKEY RRset has to be resigned. In practice there is + therefore little difference between the usage pattern of the private + + + + +Ihren, et al. Expires April 18, 2005 [Page 17] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + part of key signing keys and priming keys. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 18] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +7. IANA Considerations + + + NONE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 19] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +8. References + + +8.1 Normative References + + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + + [3] Arends, R., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-10 (work in progress), + September 2004. + + +8.2 Informative References + + + [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-12 (work in progress), September + 2004. + + + [5] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-01 (work in + progress), May 2004. + + + [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509 + Public Key Infrastructure Certificate and CRL Profile", RFC + 2459, January 1999. + + + +Authors' Addresses + + + Johan Ihren + Autonomica AB + Bellmansgatan 30 + Stockholm SE-118 47 + Sweden + + + EMail: johani@autonomica.se + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 20] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + + Bill Manning + EP.net + Marina del Rey, CA 90295 + USA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 21] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Appendix A. Acknowledgments + + + The present design for in-band automatic rollovers of DNSSEC trust + anchors is the result of many conversations and it is no longer + possible to remember exactly who contributed what. + + + In addition we've also had appreciated help from (in no particular + order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt + Larson and Mark Kosters. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 22] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Appendix B. Document History + + + This appendix will be removed if and when the document is submitted + to the RFC editor. + + + The version you are reading is tagged as $Revision: 1.1 $. + + + Text between square brackets, other than references, are editorial + comments and will be removed. + + +B.1 prior to version 00 + + + This draft was initially published as a personal submission under the + name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt. + + + Kolkman documented the ideas provided by Ihren and Manning. In the + process of documenting (and prototyping) Kolkman changed some of the + details of the M-N algorithms working. Ihren did not have a chance + to review the draft before Kolkman posted; + + + Kolkman takes responsibilities for omissions, fuzzy definitions and + mistakes. + + +B.2 version 00 + o The name of the draft was changed as a result of the draft being + adopted as a working group document. + o A small section on the concept of stale trust anchors was added. + o The different possible states are more clearly defined, including + examples of transitions between states. + o The terminology is changed throughout the document. The old term + "M-N" is replaced by "threshold" (more or less). Also the + interpretation of the constants M and N is significantly + simplified to bring the usage more in line with "standard" + threshold terminlogy. + + + + + + + + + + + + + + + + + + +Ihren, et al. Expires April 18, 2005 [Page 23] +Internet-Draft DNSSEC Threshold-based Trust Update October 2004 + + + +Intellectual Property Statement + + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + +Disclaimer of Validity + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Copyright Statement + + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + + +Acknowledgment + + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Ihren, et al. Expires April 18, 2005 [Page 24]
\ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt new file mode 100644 index 0000000..0285259 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-05.txt @@ -0,0 +1,729 @@ + + + +Network Working Group M. StJohns +Internet-Draft Nominum, Inc. +Intended status: Informational November 29, 2006 +Expires: June 2, 2007 + + + Automated Updates of DNSSEC Trust Anchors + draft-ietf-dnsext-trustupdate-timers-05 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on June 2, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes a means for automated, authenticated and + authorized updating of DNSSEC "trust anchors". The method provides + protection against N-1 key compromises of N keys in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor(s). + + This mechanism will require changes to resolver management behavior + + + +StJohns Expires June 2, 2007 [Page 1] + +Internet-Draft trustanchor-update November 2006 + + + (but not resolver resolution behavior), and the addition of a single + flag bit to the DNSKEY record. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 + 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5 + 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 + 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 + 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 + 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 + 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 + 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8 + 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9 + 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9 + 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 + 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10 + 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10 + 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 + 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11 + 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11 + 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 + 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 + Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . . . 13 + + + + + + + + + + + + + + +StJohns Expires June 2, 2007 [Page 2] + +Internet-Draft trustanchor-update November 2006 + + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has + come to the realization that there will not be one signed name space, + but rather islands of signed name space each originating from + specific points (i.e. 'trust points') in the DNS tree. Each of those + islands will be identified by the trust point name, and validated by + at least one associated public key. For the purpose of this document + we'll call the association of that name and a particular key a 'trust + anchor'. A particular trust point can have more than one key + designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties. (e.g. Consider an + unsigned ".COM".) Requiring the owner of the resolver to manually + manage this many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key replacement/ + rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g. multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1. Compliance Nomenclature + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + + + + + + + +StJohns Expires June 2, 2007 [Page 3] + +Internet-Draft trustanchor-update November 2006 + + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a + DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section + 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is + validated by an existing trust anchor, then the resolver can add the + new key to its valid set of trust anchors for that trust point. + + There are some issues with this approach which need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example, assuming a single key + compromise, we need to prevent an attacker from adding a new key and + revoking all the other old keys. + +2.1. Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set which didn't + contain A. To fix this, we add a mechanism which requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a self- + signed RRSet and the key has the REVOKE bit (see Section 7 below) set + to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this + key as a trust anchor or for any other purposes except validating the + RRSIG it signed over the DNSKEY RRSet specifically for the purpose of + validating the revocation. Unlike the 'Add' operation below, + revocation is immediate and permanent upon receipt of a valid + revocation at the resolver. + + A self-signed RRSet is a DNSKEY RRSet which contains the specific + DNSKEY and for which there is a corresponding validated RRSIG record. + It's not a special DNSKEY RRSet, just a way of describing the + validation requirements for that RRSet. + + N.B. A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent, or the fingerprint stored at a resolver + used to configure a trust point. + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + + + + +StJohns Expires June 2, 2007 [Page 4] + +Internet-Draft trustanchor-update November 2006 + + +2.2. Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key - C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in both the + attacker and owner being able to sign data in the zone and have it + accepted as valid by resolvers. + + To mitigate but not completely solve this problem, we add a hold-down + time to the addition of the trust anchor. When the resolver sees a + new SEP key in a validated trust point DNSKEY RRSet, the resolver + starts an acceptance timer, and remembers all the keys that validated + the RRSet. If the resolver ever sees the DNSKEY RRSet without the + new key but validly signed, it stops the acceptance process for that + key and resets the acceptance timer. If all of the keys which were + originally used to validate this key are revoked prior to the timer + expiring, the resolver stops the acceptance process and resets the + timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold down time which contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explictly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g. using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3. Active Refresh + + A resolver which has been configured for automatic update of keys + from a particular trust point MUST query that trust point (e.g. do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days or half the original TTL for the DNSKEY + + + +StJohns Expires June 2, 2007 [Page 5] + +Internet-Draft trustanchor-update November 2006 + + + RRSet or half the RRSIG expiration interval and no more often than + once per hour. The expiration interval is the amount of time from + when the RRSIG was last retrieved until the expiration time in the + RRSIG. + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day or 10% of the original TTL or 10% of the original + expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 * + origTTL, .1 * expireInterval)). + +2.4. Resolver Parameters + +2.4.1. Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the + original TTL of the first trust point DNSKEY RRSet which contained + the new key, whichever is greater. This ensures that at least two + validated DNSKEY RRSets which contain the new key MUST be seen by the + resolver prior to the key's acceptance. + +2.4.2. Remove Hold-Down Time + + The remove hold-down time is 30 days. This parameter is solely a key + management database bookeeping parameter. Failure to remove + information about the state of defunct keys from the database will + not adversely impact the security of this protocol, but may end up + with a database cluttered with obsolete key information. + +2.4.3. Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + + +3. Changes to DNSKEY RDATA Wire Format + + Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE' + flag. If this bit is set to '1', AND the resolver sees an + RRSIG(DNSKEY) signed by the associated key, then the resolver MUST + consider this key permanently invalid for all purposes except for + validating the revocation. + + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes that view + + + +StJohns Expires June 2, 2007 [Page 6] + +Internet-Draft trustanchor-update November 2006 + + + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + This is the state of a trust point key as seen from the resolver. + The column on the left indicates the current state. The header at + the top shows the next state. The intersection of the two shows the + event that will cause the state to transition from the current state + to the next. + + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + + State Table + +4.1. Events + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust point + after it's been present in the RRSet for at least 'add time'. + KeyPres The key has returned to the valid DNSKEY RRSet. + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + RemTime A revoked key has been missing from the trust point DNSKEY + RRSet for sufficient time to be removed from the trust set. + RevBit The key has appeared in the trust anchor DNSKEY RRSet with + its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet + signed by this key. + + + + + +StJohns Expires June 2, 2007 [Page 7] + +Internet-Draft trustanchor-update November 2006 + + +4.2. States + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but either hasn't yet + been seen at the resolver or was seen but was absent from the last + DNSKEY RRSet (e.g. KeyRem event). + AddPend The key has been seen at the resolver, has its 'SEP' bit + set, and has been included in a validated DNSKEY RRSet. There is + a hold-down time for the key before it can be used as a trust + anchor. + Valid The key has been seen at the resolver and has been included in + all validated DNSKEY RRSets from the time it was first seen up + through the hold-down time. It is now valid for verifying RRSets + that arrive after the hold down time. Clarification: The DNSKEY + RRSet does not need to be continuously present at the resolver + (e.g. its TTL might expire). If the RRSet is seen, and is + validated (i.e. verifies against an existing trust anchor), this + key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. + Missing This is an abnormal state. The key remains as a valid trust + point key, but was not seen at the resolver in the last validated + DNSKEY RRSet. This is an abnormal state because the zone operator + should be using the REVOKE bit prior to removal. + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains + this key with its REVOKE bit set to '1'. Once in this state, this + key MUST permanently be considered invalid as a trust anchor. + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed state + MUST NOT be considered a valid trust anchor. (Note: this state is + more or less equivalent to the "Start" state, except that it's bad + practice to re-introduce previously used keys - think of this as + the holding state for all the old keys for which the resolver no + longer needs to track state.) + + +5. Trust Point Deletion + + A trust point which has all of its trust anchors revoked is + considered deleted and is treated as if the trust point was never + configured. If there are no superior configured trust points, data + at and below the deleted trust point are considered insecure by the + resolver. If there ARE superior configured trust points, data at and + below the deleted trust point are evaluated with respect to the + superior trust point(s). + + Alternately, a trust point which is subordinate to another configured + trust point MAY be deleted by a resolver after 180 days where such + subordinate trust point validly chains to a superior trust point. + The decision to delete the subordinate trust anchor is a local + + + +StJohns Expires June 2, 2007 [Page 8] + +Internet-Draft trustanchor-update November 2006 + + + configuration decision. Once the subordinate trust point is deleted, + validation of the subordinate zone is dependent on validating the + chain of trust to the superior trust point. + + +6. Scenarios - Informative + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and should) be provided with additional protections + not normally available to a key that must be used frequently. E.g. + locked in a safe, split among many parties, etc. Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +6.1. Adding a Trust Anchor + + Assume an existing trust anchor key 'A'. + 1. Generate a new key pair. + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + 3. Add the DNSKEY to the RRSet. + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + 5. Wait a while (i.e. for various resolvers timers to go off and for + them to retrieve the new DNSKEY RRSet and signatures). + 6. The new trust anchor will be populated at the resolvers on the + schedule described by the state table and update algorithm - see + Section 2 above + +6.2. Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + 1. Set the revocation bit on key 'A'. + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. + 'A' is now revoked. The operator should include the revoked 'A' in + the RRSet for at least the remove hold-down time, but then may remove + it from the DNSKEY RRSet. + + + + + + +StJohns Expires June 2, 2007 [Page 9] + +Internet-Draft trustanchor-update November 2006 + + +6.3. Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been + in the DNSKEY RRSet and is a valid trust anchor, but wasn't being + used to sign the RRSet.) + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator should include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +6.4. Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 6.3) + above assuming 'A' is the active key. + +6.5. Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 6.3) above: + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' should continue to be + included in the RRSet for the remove hold-down time. + +6.6. Trust Point Deletion + + To delete a trust point which is subordinate to another configured + trust point (e.g. example.com to .com) requires some juggling of the + data. The specific process is: + 1. Generate a new DNSKEY and DS record and provide the DS record to + the parent along with DS records for the old keys + 2. Once the parent has published the DSs, add the new DNSKEY to the + RRSet and revoke ALL of the old keys at the same time while + signing the DNSKEY RRSet with all of the old and new keys. + 3. After 30 days stop publishing the old, revoked keys and remove + any corresponding DS records in the parent. + Revoking the old trust point keys at the same time as adding new keys + that chain to a superior trust prevents the resolver from adding the + new keys as trust anchors. Adding DS records for the old keys avoids + a race condition where either the subordinate zone becomes unsecure + + + +StJohns Expires June 2, 2007 [Page 10] + +Internet-Draft trustanchor-update November 2006 + + + (because the trust point was deleted) or becomes bogus (because it + didn't chain to the superior zone). + + +7. IANA Considerations + + The IANA will need to assign a bit in the DNSKEY flags field (see + section 4.3 of [RFC3755]) for the REVOKE bit. There are no other + IANA actions required. + + +8. Security Considerations + + In addition to the following sections, see also Theory of Operation + above and especially Section 2.2 for related discussions. + +8.1. Key Ownership vs Acceptance Policy + + The reader should note that, while the zone owner is responsible for + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision to + update trust anchor keys based on trust for a current trust anchor + key is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates outside the scope of this document. + +8.2. Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust + anchor key remains uncompromised. E.g. if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust anchor keys at a trust point are compromised. + +8.3. Dynamic Updates + + Allowing a resolver to update its trust anchor set based on in-band + key information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + + + +StJohns Expires June 2, 2007 [Page 11] + +Internet-Draft trustanchor-update November 2006 + + + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + + +9. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +Editorial Comments + + [msj2] msj: To be assigned. + + +Author's Address + + Michael StJohns + Nominum, Inc. + 2385 Bay Road + Redwood City, CA 94063 + USA + + Phone: +1-301-528-4729 + Email: Mike.StJohns@nominum.com + URI: www.nominum.com + + + + + + + + + + + +StJohns Expires June 2, 2007 [Page 12] + +Internet-Draft trustanchor-update November 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +StJohns Expires June 2, 2007 [Page 13] + + diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt new file mode 100644 index 0000000..00476ae --- /dev/null +++ b/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/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt new file mode 100644 index 0000000..9cf88a5 --- /dev/null +++ b/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/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt new file mode 100644 index 0000000..0855ba3 --- /dev/null +++ b/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/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt new file mode 100644 index 0000000..230c036 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt @@ -0,0 +1,672 @@ + + + +Network Working Group M. Andrews +Internet-Draft ISC +Intended status: BCP June 5, 2008 +Expires: December 7, 2008 + + + Locally-served DNS Zones + draft-ietf-dnsop-default-local-zones-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 December 7, 2008. + +Abstract + + Experience has shown that there are a number of DNS zones all + iterative resolvers and recursive nameservers should, unless + configured otherwise, automatically serve. RFC 4193 specifies that + this should occur for D.F.IP6.ARPA. This document extends the + practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space + and other well known zones with similar characteristics. + + + + + + + + + +Andrews Expires December 7, 2008 [Page 1] + +Internet-Draft Locally-served DNS Zones June 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4 + 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4 + 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5 + 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6 + 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6 + 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6 + 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7 + 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Appendix A. Change History [To Be Removed on Publication] . . . . 10 + A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10 + A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10 + A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10 + A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10 + A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11 + A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11 + A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11 + A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11 + Appendix B. Proposed Status [To Be Removed on Publication] . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + +Andrews Expires December 7, 2008 [Page 2] + +Internet-Draft Locally-served DNS Zones June 2008 + + +1. Introduction + + Experience has shown that there are a number of DNS [RFC 1034] [RFC + 1035] zones that all iterative resolvers and recursive nameservers + SHOULD, unless intentionally configured otherwise, automatically + serve. These zones include, but are not limited to, the IN-ADDR.ARPA + zones for the address space allocated by [RFC 1918] and the IP6.ARPA + zones for locally assigned unique local IPv6 addresses, [RFC 4193]. + + This recommendation is made because data has shown that significant + leakage of queries for these name spaces is occurring, despite + instructions to restrict them, and because it has therefore become + necessary to deploy sacrificial name servers to protect the immediate + parent name servers for these zones from excessive, unintentional, + query load [AS112] [I-D.draft-ietf-dnsop-as112-ops] + [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every + expectation that the query load will continue to increase unless + steps are taken as outlined here. + + Additionally, queries from clients behind badly configured firewalls + that allow outgoing queries for these name spaces but drop the + responses, put a significant load on the root servers (forward but no + reverse zones configured). They also cause operational load for the + root server operators as they have to reply to enquiries about why + the root servers are "attacking" these clients. Changing the default + configuration will address all these issues for the zones listed in + Section 4. + + [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled + locally. This document extends the recommendation to cover the IN- + ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and + IP6.ARPA zones for which queries should not appear on the public + Internet. + + It is hoped that by doing this the number of sacrificial servers + [AS112] will not have to be increased, and may in time be reduced. + + This recommendation should also help DNS responsiveness for sites + which are using [RFC 1918] addresses but do not follow the last + paragraph in Section 3 of [RFC 1918]. + +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 [RFC 2119]. + + + + + +Andrews Expires December 7, 2008 [Page 3] + +Internet-Draft Locally-served DNS Zones June 2008 + + +2. Effects on sites using RFC 1918 addresses. + + For most sites using [RFC 1918] addresses, the changes here will have + little or no detrimental effect. If the site does not already have + the reverse tree populated the only effect will be that the name + error responses will be generated locally rather than remotely. + + For sites that do have the reverse tree populated, most will either + have a local copy of the zones or will be forwarding the queries to + servers which have local copies of the zone. Therefore this + recommendation will not be relevant. + + The most significant impact will be felt at sites that make use of + delegations for [RFC 1918] addresses and have populated these zones. + These sites will need to override the default configuration expressed + in this document to allow resolution to continue. Typically, such + sites will be fully disconnected from the Internet and have their own + root servers for their own non-Internet DNS tree. + + +3. Changes to Iterative Resolver Behaviour. + + Unless configured otherwise, an iterative resolver will now return + authoritatively (aa=1) name errors (RCODE=3) for queries within the + zones in Section 4, with the obvious exception of queries for the + zone name itself where SOA, NS and "no data" responses will be + returned as appropriate to the query type. One common way to do this + is to serve empty (SOA and NS only) zones. + + An implementation of this recommendation MUST provide a mechanism to + disable this new behaviour, and SHOULD allow this decision on a zone + by zone basis. + + If using empty zones one SHOULD NOT use the same NS and SOA records + as used on the public Internet servers as that will make it harder to + detect the origin of the responses and thus any leakage to the public + Internet servers. This document recommends that the NS record + defaults to the name of the zone and the SOA MNAME defaults to the + name of the only NS RR's target. The SOA RNAME should default to + "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a + mechanism to set these values. No address records need to be + provided for the name server. + + Below is an example of a generic empty zone in master file format. + It will produce a negative cache TTL of 3 hours. + + @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800 + @ 10800 IN NS @ + + + +Andrews Expires December 7, 2008 [Page 4] + +Internet-Draft Locally-served DNS Zones June 2008 + + + The SOA RR is needed to support negative caching [RFC 2308] of name + error responses and to point clients to the primary master for DNS + dynamic updates. + + SOA values of particular importance are the MNAME, the SOA RR's TTL + and the negTTL value. Both TTL values SHOULD match. The rest of the + SOA timer values MAY be chosen arbitrarily since they are not + intended to control any zone transfer activity. + + The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries + to discover the zone to be updated. Having no address records for + the name server is expected to abort UPDATE processing in the client. + + +4. Lists Of Zones Covered + + The following subsections are intended to seed the IANA registry as + requested in the IANA Considerations Section. The zone name is the + entity to be registered. + +4.1. RFC 1918 Zones + + The following zones correspond to the IPv4 address space reserved in + [RFC 1918]. + + +----------------------+ + | Zone | + +----------------------+ + | 10.IN-ADDR.ARPA | + | 16.172.IN-ADDR.ARPA | + | 17.172.IN-ADDR.ARPA | + | 18.172.IN-ADDR.ARPA | + | 19.172.IN-ADDR.ARPA | + | 20.172.IN-ADDR.ARPA | + | 21.172.IN-ADDR.ARPA | + | 22.172.IN-ADDR.ARPA | + | 23.172.IN-ADDR.ARPA | + | 24.172.IN-ADDR.ARPA | + | 25.172.IN-ADDR.ARPA | + | 26.172.IN-ADDR.ARPA | + | 27.172.IN-ADDR.ARPA | + | 28.172.IN-ADDR.ARPA | + | 29.172.IN-ADDR.ARPA | + | 30.172.IN-ADDR.ARPA | + | 31.172.IN-ADDR.ARPA | + | 168.192.IN-ADDR.ARPA | + +----------------------+ + + + + +Andrews Expires December 7, 2008 [Page 5] + +Internet-Draft Locally-served DNS Zones June 2008 + + +4.2. RFC 3330 Zones + + The following zones correspond to those address ranges from [RFC + 3330] that are not expected to appear as source or destination + addresses on the public Internet and to not have a unique name to + associate with. + + The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a + attempt to discourage any practice to provide a PTR RR for + 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse + mapping should exist, but the exact setup is out of the scope of this + document. Similar logic applies to the reverse mapping for ::1 + (Section 4.3). The recommendations made here simply assume no other + coverage for these domains exists. + + +------------------------------+------------------------+ + | Zone | Description | + +------------------------------+------------------------+ + | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK | + | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK | + | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL | + | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET | + | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST | + +------------------------------+------------------------+ + +4.3. Local IPv6 Unicast Addresses + + The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for + the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291], + Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones: + + +-------------------------------------------+ + | Zone | + +-------------------------------------------+ + | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | + | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | + | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ | + | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA | + +-------------------------------------------+ + + Note: Line breaks and a escapes '\' have been inserted above for + readability and to adhere to line width constraints. They are not + parts of the zone names. + +4.4. IPv6 Locally Assigned Local Addresses + + Section 4.4 of [RFC 4193] already required special treatment of: + + + + +Andrews Expires December 7, 2008 [Page 6] + +Internet-Draft Locally-served DNS Zones June 2008 + + + +--------------+ + | Zone | + +--------------+ + | D.F.IP6.ARPA | + +--------------+ + +4.5. IPv6 Link Local Addresses + + IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered + by four distinct reverse DNS zones: + + +----------------+ + | Zone | + +----------------+ + | 8.E.F.IP6.ARPA | + | 9.E.F.IP6.ARPA | + | A.E.F.IP6.ARPA | + | B.E.F.IP6.ARPA | + +----------------+ + + +5. Zones that are Out-Of-Scope + + IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and + IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered + here. It is expected that IPv6 site-local addresses will be self + correcting as IPv6 implementations remove support for site-local + addresses. However, sacrificial servers for C.E.F.IP6.ARPA through + F.E.F.IP6.ARPA may still need to be deployed in the short term if the + traffic becomes excessive. + + For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193], + there has been no decision made about whether the Regional Internet + Registries (RIRs) will provide delegations in this space or not. If + they don't, then C.F.IP6.ARPA will need to be added to the list in + Section 4.4. If they do, then registries will need to take steps to + ensure that name servers are provided for these addresses. + + This document also ignores IP6.INT. IP6.INT has been wound up with + only legacy resolvers now generating reverse queries under IP6.INT + [RFC 4159]. + + This document has also deliberately ignored names immediately under + the root domain. While there is a subset of queries to the root name + servers which could be addressed using the techniques described here + (e.g. .local, .workgroup and IPv4 addresses), there is also a vast + amount of traffic that requires a different strategy (e.g. lookups + for unqualified hostnames, IPv6 addresses). + + + +Andrews Expires December 7, 2008 [Page 7] + +Internet-Draft Locally-served DNS Zones June 2008 + + +6. IANA Considerations + + This document requests that IANA establish a registry of zones which + require this default behaviour. The initial contents of which are in + Section 4. Implementors are encouraged to check this registry and + adjust their implementations to reflect changes therein. + + This registry can be amended through "IETF Consensus" as per [RFC + 2434]. + + IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is + deployed in the reverse tree, delegations for these zones are made in + the manner described in Section 7. + + +7. Security Considerations + + During the initial deployment phase, particularly where [RFC 1918] + addresses are in use, there may be some clients that unexpectedly + receive a name error rather than a PTR record. This may cause some + service disruption until their recursive name server(s) have been re- + configured. + + As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA + namespaces, the zones listed above will need to be delegated as + insecure delegations, or be within insecure zones. This will allow + DNSSEC validation to succeed for queries in these spaces despite not + being answered from the delegated servers. + + It is recommended that sites actively using these namespaces secure + them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust + anchors. This will protect the clients from accidental import of + unsigned responses from the Internet. + + +8. Acknowledgements + + This work was supported by the US National Science Foundation + (research grant SCI-0427144) and DNS-OARC. + + +9. References + +9.1. Normative References + + [RFC 1034] + Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", + STD 13, RFC 1034, November 1987. + + + +Andrews Expires December 7, 2008 [Page 8] + +Internet-Draft Locally-served DNS Zones June 2008 + + + [RFC 1035] + Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND + SPECIFICATION", STD 13, RFC 1035, November 1987. + + [RFC 1918] + Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC 2119] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2136] + Vixie, P., Thomson, A., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC 2308] + Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2398, March 1998. + + [RFC 2434] + Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC 2606] + Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999. + + [RFC 3596] + Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IPv6", RFC 3596, October 2003. + + [RFC 4035] + Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC 4159] + Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159, + August 2005. + + [RFC 4193] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + + + +Andrews Expires December 7, 2008 [Page 9] + +Internet-Draft Locally-served DNS Zones June 2008 + + + [RFC 4291] + Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +9.2. Informative References + + [AS112] "AS112 Project", <http://www.as112.net/>. + + [I-D.draft-ietf-dnsop-as112-ops] + Abley, J. and W. Maton, "AS112 Nameserver Operations", + draft-ietf-dnsop-as112-ops-00 (work in progress), + February 2007. + + [I-D.draft-ietf-dnsop-as112-under-attack-help-help] + Abley, J. and W. Maton, "I'm Being Attacked by + PRISONER.IANA.ORG!", + draft-ietf-dnsop-as112-under-attack-help-help-00 (work in + progress), February 2007. + + [RFC 3330] + "Special-Use IPv4 Addresses", RFC 3330, September 2002. + + +Appendix A. Change History [To Be Removed on Publication] + +A.1. draft-ietf-dnsop-default-local-zones-05.txt + + none, expiry prevention + +A.2. draft-ietf-dnsop-default-local-zones-04.txt + + Centrally Assigned Local addresses -> Non-Locally Assigned Local + address + +A.3. draft-ietf-dnsop-default-local-zones-03.txt + + expanded section 4 descriptions + + Added references [RFC 2136], [RFC 3596], + [I-D.draft-ietf-dnsop-as112-ops] and + [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. + + Revised language. + +A.4. draft-ietf-dnsop-default-local-zones-02.txt + + RNAME now "nobody.invalid." + + + + +Andrews Expires December 7, 2008 [Page 10] + +Internet-Draft Locally-served DNS Zones June 2008 + + + Revised language. + +A.5. draft-ietf-dnsop-default-local-zones-01.txt + + Revised impact description. + + Updated to reflect change in IP6.INT status. + +A.6. draft-ietf-dnsop-default-local-zones-00.txt + + Adopted by DNSOP. + + "Author's Note" re-titled "Zones that are Out-Of-Scope" + + Add note that these zone are expected to seed the IANA registry. + + Title changed. + +A.7. draft-andrews-full-service-resolvers-03.txt + + Added "Proposed Status". + +A.8. draft-andrews-full-service-resolvers-02.txt + + Added 0.IN-ADDR.ARPA. + + +Appendix B. Proposed Status [To Be Removed on Publication] + + This Internet-Draft is being submitted for eventual publication as an + RFC with a proposed status of Best Current Practice. + + +Author's Address + + Mark P. Andrews + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + US + + Email: Mark_Andrews@isc.org + + + + + + + + + +Andrews Expires December 7, 2008 [Page 11] + +Internet-Draft Locally-served DNS Zones June 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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. + + + + + + + + + + + +Andrews Expires December 7, 2008 [Page 12] + diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt new file mode 100644 index 0000000..bcd0d14 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt @@ -0,0 +1,396 @@ + + + + + + +INTERNET-DRAFT D. Senie +Category: BCP Amaranth Networks Inc. +Expires in six months July 2005 + + Encouraging the use of DNS IN-ADDR Mapping + draft-ietf-dnsop-inaddr-required-07.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 + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. + +Copyright Notice + + Copyright (C) The Internet Society. (2005) + +1. Introduction + + The Domain Name Service has provision for providing mapping of IP + addresses to host names. It is common practice to ensure both name to + address, and address to name mappings are provided for networks. This + practice, while documented, has never been required, though it is + generally encouraged. This document both encourages the presence of + + + +Senie [Page 1] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + these mappings and discourages reliance on such mappings for security + checks. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Discussion + + + From the early days of the Domain Name Service [RFC883] a special + domain has been set aside for resolving mappings of IP addresses to + domain names. This was refined in [RFC1035], describing the .IN- + ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA + was added [RFC3152]. This document uses IPv4 CIDR block sizes and + allocation strategy where there are differences and uses IPv4 + terminology. Aside from these differences, this document can and + should be applied to both address spaces. + + The assignment of blocks of IP address space was delegated to three + regional registries. Guidelines for the registries are specified in + [RFC2050], which requires regional registries to maintain IN-ADDR + records on the large blocks of space issued to ISPs and others. + + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to + update IN-ADDR, however the present version of its policy document + for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft + copies of this document. As of this writing, it appears APNIC has no + actual policy on IN-ADDR. RIPE appears to have the strongest policy + in this area [RIPE302] indicating Local Internet Registries should + provide IN-ADDR services, and delegate those as appropriate when + address blocks are delegated. + + As we can see, the regional registries have their own policies for + recommendations and/or requirements for IN-ADDR maintenance. It + should be noted, however, that many address blocks were allocated + before the creation of the regional registries, and thus it is + unclear whether any of the policies of the registries are binding on + those who hold blocks from that era. + + Registries allocate address blocks on CIDR [RFC1519] boundaries. + Unfortunately the IN-ADDR zones are based on classful allocations. + Guidelines [RFC2317] for delegating on non-octet-aligned boundaries + exist, but are not always implemented. + +3. Examples of impact of missing IN-ADDR + + + +Senie [Page 2] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + These are some examples of problems that may be introduced by + reliance on IN-ADDR. + + Some applications use DNS lookups for security checks. To ensure + validity of claimed names, some applications will look up IN-ADDR + records to get names, and then look up the resultant name to see if + it maps back to the address originally known. Failure to resolve + matching names is seen as a potential security concern. + + Some FTP sites will flat-out reject users, even for anonymous FTP, if + the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when + itself resolved, does not match. Some Telnet servers also implement + this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This + approach has been employed for downloads of crypto software, for + example, where export of that software is prohibited to some locales. + Credit card anti-fraud systems also use these methods for geographic + placement purposes. + + The popular TCP Wrappers program found on most Unix and Linux systems + has options to enforce IN-ADDR checks and to reject any client that + does not resolve. This program also has a way to check to see that + the name given by a PTR record then resolves back to the same IP + address. This method provdes more comfort but no appreciable + additional security. + + Some anti-spam (anti junk email) systems use IN-ADDR to verify the + presence of a PTR record, or validate the PTR value points back to + the same address. + + Many web servers look up the IN-ADDR of visitors to be used in log + analysis. This adds to the server load, but in the case of IN-ADDR + unavailability, it can lead to delayed responses for users. + + Traceroutes with descriptive IN-ADDR naming proves useful when + debugging problems spanning large areas. When this information is + missing, the traceroutes take longer, and it takes additional steps + to determine that network is the cause of problems. + + Wider-scale implementation of IN-ADDR on dialup, wireless access and + other such client-oriented portions of the Internet would result in + lower latency for queries (due to lack of negative caching), and + lower name server load and DNS traffic. + +4. Recommendations + + + + +Senie [Page 3] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 4.1 Delegation Recommendations + + + Regional Registries and any Local Registries to whom they delegate + should establish and convey a policy to those to whom they delegate + blocks that IN-ADDR mappings are recommended. Policies should + recommend those receiving delegations to provide IN-ADDR service + and/or delegate to downstream customers. + + Network operators should define and implement policies and procedures + which delegate IN-ADDR to their clients who wish to run their own IN- + ADDR DNS services, and provide IN-ADDR services for those who do not + have the resources to do it themselves. Delegation mechanisms should + permit the downstream customer to implement and comply with IETF + recommendations application of IN-ADDR to CIDR [RFC2317]. + + All IP address space assigned and in use should be resolved by IN- + ADDR records. All PTR records must use canonical names. + + All IP addresses in use within a block should have an IN-ADDR + mapping. Those addresses not in use, and those that are not valid for + use (zeros or ones broadcast addresses within a CIDR block) need not + have mappings. + + It should be noted that due to CIDR, many addresses that appear to be + otherwise valid host addresses may actually be zeroes or ones + broadcast addresses. As such, attempting to audit a site's degree of + compliance may only be done with knowledge of the internal subnet + architecture of the site. It can be assumed, however, any host that + originates an IP packet necessarily will have a valid host address, + and must therefore have an IN-ADDR mapping. + +4.2 Application Recommendations + + + Applications SHOULD NOT rely on IN-ADDR for proper operation. The use + of IN-ADDR, sometimes in conjunction with a lookup of the name + resulting from the PTR record provides no real security, can lead to + erroneous results and generally just increases load on DNS servers. + Further, in cases where address block holders fail to properly + configure IN-ADDR, users of those blocks are penalized. + +5. Security Considerations + + This document has no negative impact on security. While it could be + argued that lack of PTR record capabilities provides a degree of + anonymity, this is really not valid. Trace routes, whois lookups and + other sources will still provide methods for discovering identity. + + + +Senie [Page 4] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + By recommending applications avoid using IN-ADDR as a security + mechanism this document points out that this practice, despite its + use by many applications, is an ineffective form of security. + Applications should use better mechanisms of authentication. + +6. IANA Considerations + + There are no IANA considerations for this document. + +7. References + +7.1 Normative References + + [RFC883] P.V. Mockapetris, "Domain names: Implementation + specification," RFC883, November 1983. + + [RFC1035] P.V. Mockapetris, "Domain Names: Implementation + Specification," RFC 1035, November 1987. + + [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): + an Address Assignment and Aggregation Strategy," RFC 1519, September + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + + [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August + 2001. + +7.2 Informative References + + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date + unknown, http://www.arin.net/regserv/initial-isp.html + + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, 13 January 2003. + + [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6 + Address Space in the RIPE NCC Service Region", RIPE-302, April 26, + + + +Senie [Page 5] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 2004. http://www.ripe.net//ripe/docs/rev-del.html + + + +8. Acknowledgements + + Thanks to Peter Koch and Gary Miller for their input, and to many + people who encouraged me to write this document. + +9. Author's Address + + Daniel Senie + Amaranth Networks Inc. + 324 Still River Road + Bolton, MA 01740 + + Phone: (978) 779-5100 + + EMail: dts@senie.com + +10. Full 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. + + 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. + + + + +Senie [Page 6] + +Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005 + + + 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. + + 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 + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + +Senie [Page 7] + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt new file mode 100644 index 0000000..bf2afcd --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt @@ -0,0 +1,1848 @@ + + + +DNS Operations WG J. Jeong, Ed. +Internet-Draft ETRI/University of Minnesota +Expires: November 6, 2005 May 5, 2005 + + + IPv6 Host Configuration of DNS Server Information Approaches + draft-ietf-dnsop-ipv6-dns-configuration-06.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 6, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational attributes + of three solutions: RA option, DHCPv6 option, and Well-known anycast + addresses for recursive DNS servers. Additionally, it suggests the + deployment scenarios in four kinds of networks, such as ISP, + Enterprise, 3GPP, and Unmanaged networks, considering multi-solution + resolution. Therefore, this document will give the audience a + + + +Jeong Expires November 6, 2005 [Page 1] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + guideline for IPv6 host DNS configuration. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 2] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7 + 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8 + 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9 + 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11 + 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12 + 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12 + 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12 + 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13 + 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14 + 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14 + 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15 + 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 + 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16 + 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17 + 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17 + 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17 + 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.3.1 Currently Available Mechanisms and Recommendations . . 19 + 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19 + 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20 + 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21 + 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21 + 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22 + 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22 + 5.4.2 Case B: A dual-stack gateway connected to a + dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22 + 5.4.3 Case C: A dual-stack gateway connected to an + IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22 + 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25 + 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25 + 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25 + 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29 + 9.2 Informative References . . . . . . . . . . . . . . . . . . 29 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31 + A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32 + + + +Jeong Expires November 6, 2005 [Page 3] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + Intellectual Property and Copyright Statements . . . . . . . . 33 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 4] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide the ways to configure either fixed or + mobile nodes with one or more IPv6 addresses, default routes and some + other parameters [3][4]. To support the access to additional + services in the Internet that are identified by a DNS name, such as a + web server, the configuration of at least one recursive DNS server is + also needed for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 + option [5]-[7], and (c) Well-known anycast addresses for recursive + DNS servers [9]. Also, it suggests the applicable scenarios for four + kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP + network, and (d) Unmanaged network. + + This document is just an analysis of each possible approach, and does + not make any recommendation on a particular one or on a combination + of particular ones. Some approaches may even not be adopted at all + as a result of further discussion. + + Therefore, the objective of this document is to help the audience + select the approaches suitable for IPv6 host configuration of + recursive DNS servers. + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 5] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +2. Terminology + + This document uses the terminology described in [3]-[9]. In + addition, a new term is defined below: + + o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name + server that offers the recursive service of DNS name resolution. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 6] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of the three solutions + are described in detail. + +3.1 RA Option + + The RA approach is to define a new ND option called the RDNSS option + that contains a recursive DNS server address. Existing ND transport + mechanisms (i.e., advertisements and solicitations) are used. This + works in the same way that nodes learn about routers and prefixes. + An IPv6 host can configure the IPv6 addresses of one or more RDNSSes + via RA message periodically sent by a router or solicited by a Router + Solicitation (RS) [8]. + + This approach needs RDNSS information to be configured in the routers + doing the advertisements. The configuration of RDNSS addresses can + be performed manually by an operator or other ways, such as automatic + configuration through a DHCPv6 client running on the router. When + advertising more than one RDNSS option, an RA message includes as + many RDNSS options as RDNSSes. + + Through the ND protocol and RDNSS option along with a prefix + information option, an IPv6 host can perform its network + configuration of its IPv6 address and RDNSS simultaneously [3][4]. + The RA option for RDNSS can be used on any network that supports the + use of ND. + + However, it is worth noting that some link layers, such as Wireless + LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast, + which means that they cannot guarantee the timely delivery of RA + messages [25]-[28]. This is discussed in Appendix A. + + The RA approach is useful in some mobile environments where the + addresses of the RDNSSes are changing because the RA option includes + a lifetime field that allows client to use RDNSSes nearer to the + client. This can be configured to a value that will require the + client to time out the entry and switch over to another RDNSS address + [8]. However, from the viewpoint of implementation, the lifetime + field would seem to make matters a bit more complex. Instead of just + writing to a DNS configuration file, such as resolv.conf for the list + of RDNSS addresses, we have to have a daemon around (or a program + that is called at the defined intervals) that keeps monitoring the + lifetime of RDNSSes all the time. + + The preference value of RDNSS, included in the RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes; this can be + used for the load balancing of RDNSSes [8]. + + + +Jeong Expires November 6, 2005 [Page 7] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +3.1.1 Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1. The RA option is an extension of existing ND/Autoconfig + mechanisms [3][4], and does not require a change in the base ND + protocol. + + 2. This approach, like ND, works well on a variety of link types + including point-to-point links, point-to-multipoint, and + multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461 + [3] states, however, that there may be some link types on which + ND is not feasible; on such links, some other mechanisms will be + needed for DNS configuration. + + 3. All of the information a host needs to run the basic Internet + applications such as the email, web, ftp, etc., can be obtained + with the addition of this option to ND and address + autoconfiguration. The use of a single mechanism is more + reliable and easier to provide than when the RDNSS information is + learned via another protocol mechanism. Debugging problems when + multiple protocol mechanisms are being used is harder and much + more complex. + + 4. This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that support + broadcast reliably (e.g., Ethernet LANs) but not necessarily on + other links (e.g., Wireless LANs): Refer to Appendix A. Also, + this works well on links that are high performance (e.g., + Ethernet LANs) and low performance (e.g., Cellular networks). In + the latter case, by combining the RDNSS information with the + other information in the RA, the host can learn all of the + information needed to use most Internet applications, such as the + web in a single packet. This not only saves bandwidth where this + is an issue, but also minimizes the delay needed to learn the + RDNSS information. + + 5. The RA approach could be used as a model for other similar types + of configuration information. New RA options for other server + addresses, such as NTP server address, that are common to all + clients on a subnet would be easy to define. + + +3.1.2 Disadvantages + + 1. ND is mostly implemented in the kernel of operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS servers, ND should be extended in the + + + +Jeong Expires November 6, 2005 [Page 8] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + kernel, and complemented by a user-land process. DHCPv6, + however, has more flexibility for the extension of service + discovery because it is an application layer protocol. + + 2. The current ND framework should be modified to facilitate the + synchronization between another ND cache for RDNSSes in the + kernel space and the DNS configuration file in the user space. + Because it is unacceptable to write and rewrite to the DNS + configuration file (e.g., resolv.conf) from the kernel, another + approach is needed. One simple approach to solve this is to have + a daemon listening to what the kernel conveys, and to have the + daemon do these steps, but such a daemon is not needed with the + current ND framework. + + 3. It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be + configured via the RA option. + + +3.1.3 Observations + + The proposed RDNSS RA option along with the IPv6 ND and + Autoconfiguration allows a host to obtain all of the information it + needs to access the basic Internet services like the web, email, ftp, + etc. This is preferable in the environments where hosts use RAs to + autoconfigure their addresses and all the hosts on the subnet share + the same router and server addresses. If the configuration + information can be obtained from a single mechanism, it is preferable + because it does not add additional delay, and it uses a minimum of + bandwidth. The environments like this include the homes, public + cellular networks, and enterprise environments where no per host + configuration is needed, but exclude public WLAN hot spots. + + DHCPv6 is preferable where it is being used for address configuration + and if there is a need for host specific configuration [5]-[7]. The + environments like this are most likely to be the enterprise + environments where the local administration chooses to have per host + configuration control. + +Note + + The observation section is based on what the proponents of each + approach think makes a good overall solution. + +3.2 DHCPv6 Option + + DHCPv6 [5] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + + + +Jeong Expires November 6, 2005 [Page 9] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + servers [7]. The DNS Recursive Name Server option carries a list of + IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by the + DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as stateless + DHCPv6 [6]. + + Stateless DHCPv6 can be deployed either using DHCPv6 servers running + on general-purpose computers, or on router hardware. Several router + vendors currently implement stateless DHCPv6 servers. Deploying + stateless DHCPv6 in routers has the advantage that no special + hardware is required, and should work well for networks where DHCPv6 + is needed for very straightforward configuration of network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router - it can be on a general + purpose computer. This has the potential to give the operator of the + DHCPv6 server more flexibility in how the DHCPv6 server responds to + individual clients - clients can easily be given different + configuration information based on their identity, or for any other + reason. Nothing precludes adding this flexibility to a router, but + generally in current practice, DHCP servers running on general- + purpose hosts tend to have more configuration options than those that + are embedded in routers. + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use a stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. Using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group is currently studying an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns + a lifetime to configuration information obtained through DHCPv6. At + the expiration of the lifetime, the host contacts the DHCPv6 server + to obtain updated configuration information, including the list of + RDNSSes. This lifetime gives the network administrator another + mechanism to configure hosts with new RDNSSes by controlling the time + at which the host refreshes the list. + + + +Jeong Expires November 6, 2005 [Page 10] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + The DHC Working Group has also discussed the possibility of defining + an extension to DHCPv6 that would allow the use of multicast to + provide configuration information to multiple hosts with a single + DHCPv6 message. Because of the lack of deployment experience, the WG + has deferred consideration of multicast DHCPv6 configuration at this + time. Experience with DHCPv4 has not identified a requirement for + multicast message delivery, even in large service provider networks + with tens of thousands of hosts that may initiate a DHCPv4 message + exchange simultaneously. + +3.2.1 Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1. DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. So configuring + DHCPv6 servers allows the network administrator to configure + RDNSSes along with the addresses of other network services, as + well as location-specific information like time zones. + + 2. As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be + managed through a single service, typically with a single user + interface and a single configuration database. + + 3. DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes as well as with other + configuration information. This capability is important in some + network deployments such as service provider networks or WiFi hot + spots. + + 4. A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5. Hosts that require other configuration information such as the + addresses of SIP servers and NTP servers are likely to need + DHCPv6 for other configuration information. + + 6. The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions such as new + options are necessary. + + 7. Interoperability among independent implementations has been + demonstrated. + + + + +Jeong Expires November 6, 2005 [Page 11] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +3.2.2 Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These include: + + 1. Update currently requires message from server (however, see + [10]). + + 2. Because DNS information is not contained in RA messages, the host + must receive two messages from the router, and must transmit at + least one message to the router. On networks where bandwidth is + at a premium, this is a disadvantage, although on most networks + it is not a practical concern. + + 3. Increased latency for initial configuration - in addition to + waiting for an RA message, the client must now exchange packets + with a DHCPv6 server; even if it is locally installed on a + router, this will slightly extend the time required to configure + the client. For clients that are moving rapidly from one network + to another, this will be a disadvantage. + + +3.2.3 Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in addition + to a list of RDNSSes or if hosts must be configured selectively, + those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive + name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, on a cell phone network, where bandwidth is at a premium and + extremely low latency is desired. The final DNS configuration draft + should be written so as to allow these special applications to be + handled using DNS information in the RA packet. + +3.3 Well-known Anycast Addresses + + Anycast uses the same routing system as unicast [11]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peers routes to their internal anycast servers, if + they want to prohibit external access from some peers to the servers. + If some advertisement is inevitable (such as the case with default + routes), the packets to the servers should be blocked at the boundary + + + +Jeong Expires November 6, 2005 [Page 12] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + of the entities. Thus, for this anycast, not only unicast routing + but also unicast ND protocols can be used as is. + + First of all, the well-known anycast addresses approach is much + different from that discussed at IPv6 Working Group in the past [9]. + It should be noted that "anycast" in this memo is simpler than that + of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be + prohibited to have multiple servers on a single link sharing an + anycast address. That is, on a link, an anycast address is assumed + to be unique. DNS clients today already have redundancy by having + multiple well-known anycast addresses configured as RDNSS addresses. + There is no point in having multiple RDNSSes sharing an anycast + address on a single link. + + The approach with well-known anycast addresses is to set multiple + well-known anycast addresses in clients' resolver configuration files + from the beginning, say, as factory default. Thus, there is no + transport mechanism and no packet format [9]. + + An anycast address is an address shared by multiple servers (in this + case, the servers are RDNSSes). A request from a client to the + anycast address is routed to a server selected by the routing system. + However, it is a bad idea to mandate "site" boundary on anycast + addresses, because most users just do not have their own servers and + want to access their ISPs' across their site boundaries. Larger + sites may also depend on their ISPs or may have their own RDNSSes + within "site" boundaries. + +3.3.1 Advantages + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, + + 1. There is no delay to get the response and no further delay by + packet losses. + + 2. The approach can be combined with any other configuration + mechanisms, such as the RA-based approach and DHCP based + approach, as well as the factory default configuration. + + 3. The approach works over any environment where DNS works. + + Another advantage is that the approach needs to configure DNS servers + as a router, but nothing else. Considering that DNS servers do need + configuration, the amount of overall configuration effort is + proportional to the number of the DNS servers and scales linearly. + It should be noted that, in the simplest case where a subscriber to + an ISP does not have any DNS server, the subscriber naturally + + + +Jeong Expires November 6, 2005 [Page 13] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + accesses DNS servers of the ISP even though the subscriber and the + ISP do nothing and there is no protocol to exchange DNS server + information between the subscriber and the ISP. + +3.3.2 Disadvantages + + Well-known anycast addresses approach requires that DNS servers (or + routers near it as a proxy) act as routers to advertise their anycast + addresses to the routing system, which requires some configuration + (see the last paragraph of the previous section on the scalability of + the effort). + +3.3.3 Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce the configuration effort of users. + + The redundancy by multiple RDNSSes is better provided by multiple + servers having different anycast addresses than multiple servers + sharing the same anycast address because the former approach allows + stale servers to still generate routes to their anycast addresses. + Thus, in a routing domain (or domains sharing DNS servers), there + will be only one server having an anycast address unless the domain + is so large that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address which is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, where + the boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be able + to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC 1546 [11] + and RFC 3513 [12] where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related + instability disappears. Thus, anycast in well-known anycast + addresses approach can and should use the anycast address as a source + unicast (according to RFC 3513 [12]) address of packets of UDP and + TCP responses. With TCP, if a route flips and packets to an anycast + address are routed to a new server, it is expected that the flip is + detected by ICMP or sequence number inconsistency and the TCP + connection is reset and retried. + + + + +Jeong Expires November 6, 2005 [Page 14] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork each other. + + For ordering between RA and DHCP approaches, the O (Other stateful + configuration) flag in RA message can be used [8][32]. If no RDNSS + option is included, an IPv6 host may perform DNS configuration + through DHCPv6 [5]-[7] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses as + the default configuration. Moreover, the clients preconfigured with + the well-known anycast addresses can be further configured to use + other approaches to override the well-known addresses, if the + configuration information from other approaches is available. + Otherwise, all the clients need to have the well-known anycast + addresses preconfigured. In order to use the anycast approach along + with two other approaches, there are three choices as follows: + + 1. The first choice is that well-known addresses are used as last + resort, when an IPv6 host cannot get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be + preconfigured in all of IPv6 hosts' resolver configuration files. + + 2. The second is that an IPv6 host can configure well-known + addresses as the most preferable in its configuration file even + though either an RA option or DHCP option is available. + + 3. The last is that the well-known anycast addresses can be set in + RA or DHCP configuration to reduce the configuration effort of + users. According to either the RA or DHCP mechanism, the well- + known addresses can be obtained by an IPv6 host. Because this + approach is the most convenient for users, the last option is + recommended. + + +Note + + This section does not necessarily mean this document suggests + adopting all these three approaches and making them interwork in the + way described here. In fact, some approaches may even not be adopted + at all as a result of further discussion. + + + + + +Jeong Expires November 6, 2005 [Page 15] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +5. Deployment Scenarios + + Regarding the DNS configuration on the IPv6 host, several mechanisms + are being considered at the DNSOP Working Group such as RA option, + DHCPv6 option and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. In + this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + +Note + + In the applicable scenarios, authors do not implicitly push any + specific approaches into the restricted environments. No enforcement + is in each scenario and all mentioned scenarios are probable. The + main objective of this work is to provide a useful guideline for IPv6 + DNS configuration. + +5.1 ISP Network + + A characteristic of ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and each PE connects multiple CPE devices to the backbone + network infrastructure [13]. The CPEs may be hosts or routers. + + In the case where the CPE is a router, there is a customer network + that is connected to the ISP backbone through the CPE. Typically, + each customer network gets a different IPv6 prefix from an IPv6 PE + router, but the same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1 RA Option Approach + + When the CPE is a host, the RA option for RDNSS can be used to allow + the CPE to get RDNSS information as well as /64 prefix information + for stateless address autoconfiguration at the same time when the + host is attached to a new subnet [8]. Because an IPv6 host must + receive at least one RA message for stateless address + autoconfiguration and router configuration, the host could receive + RDNSS configuration information in that RA without the overhead of an + additional message exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP, and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in which + + + +Jeong Expires November 6, 2005 [Page 16] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + the host must receive at least an RA message for detecting a new + network, than in other scenarios generally although administrator + should configure RDNSS information on the routers. Secure ND [14] + can provide extended security when using RA messages. + +5.1.2 DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the DNS + option, and can provide other configuration information in the same + message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is + already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or + stateless DHCP [6] is nowhere as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISPs can + handle user identification on its network intentionally, and also + authenticated DHCP [15] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the customer + gateway to assign a /64 prefix to each network in the customer's + network. Prefix delegation with DHCP (DHCPv6 PD) has already been + adopted by ISPs for automating the assignment of the customer prefix + to the customer gateway [17]. DNS configuration can be carried in + the same DHCPv6 message exchange used for DHCPv6 to efficiently + provide that information, along with any other configuration + information needed by the customer gateway or customer network. This + service model can be useful to Home or SOHO subscribers. The Home or + SOHO gateway, which is a customer gateway for ISP, can then pass that + RDNSS configuration information to the hosts in the customer network + through DHCP. + +5.1.3 Well-known Anycast Addresses Approach + + The well-known anycast addresses approach is also a feasible and + simple mechanism for ISP [9]. The use of well-known anycast + addresses avoids some of the security risks in rogue messages sent + through an external protocol like RA or DHCPv6. The configuration of + hosts for the use of well-known anycast addresses requires no + protocol or manual configuration, but the configuration of routing + for the anycast addresses requires intervention on the part of the + network administrator. Also, the number of special addresses would + be equal to the number of RDNSSes that could be made available to + subscribers. + +5.2 Enterprise Network + + Enterprise network is defined as a network that has multiple internal + links, one or more router connections, to one or more Providers and + is actively managed by a network operations entity [16]. An + + + +Jeong Expires November 6, 2005 [Page 17] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + enterprise network can get network prefixes from an ISP by either + manual configuration or prefix delegation [17]. In most cases, + because an enterprise network manages its own DNS domains, it + operates its own DNS servers for the domains. These DNS servers + within enterprise network process recursive DNS name resolution + requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the + enterprise network can be performed like in Section 4, in which three + approaches can be used together as follows: + + 1. An IPv6 host can decide which approach is or may be used in its + subnet with the O flag in RA message [8][32]. As the first + choice in Section 4, well-known anycast addresses can be used as + a last resort when RDNSS information cannot be obtained through + either an RA option or DHCP option. This case needs IPv6 hosts + to preconfigure the well-known anycast addresses in their DNS + configuration files. + + 2. When the enterprise prefers the well-known anycast approach to + others, IPv6 hosts should preconfigure the well-known anycast + addresses like in the first choice. + + 3. The last choice, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + because the addresses are delivered to IPv6 hosts via either the + RA option or DHCPv6 option as if they were unicast addresses. + This way is most recommended for the sake of user's convenience. + + +5.3 3GPP Network + + The IPv6 DNS configuration is a missing part of IPv6 + autoconfiguration and an important part of the basic IPv6 + functionality in the 3GPP User Equipment (UE). The higher level + description of the 3GPP architecture can be found in [18], and + transition to IPv6 in 3GPP networks is analyzed in [19] and [20]. + + In the 3GPP architecture, there is a dedicated link between the UE + and the GGSN called the Packet Data Protocol (PDP) Context. This + link is created through the PDP Context activation procedure [21]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If a + 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP + context), it cannot be assumed that (s)he has simultaneously an + active IPv4 PDP context, and DNS queries could be done using IPv4. A + 3GPP UE can thus be an IPv6 node, and it needs to somehow discover + the address of the RDNSS. Before IP-based services (e.g., web + browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses + need to be discovered in the 3GPP UE. + + + + +Jeong Expires November 6, 2005 [Page 18] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the Well-known addresses approach. + Section 5.3.5 finally summarizes the recommendations. + +5.3.1 Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism, in which RDNSS addresses can be + received in the PDP context activation (a control plane mechanism). + That is called the Protocol Configuration Options Information Element + (PCO-IE) mechanism [22]. The RDNSS addresses can also be received + over the air (using text messages), or typed in manually in the UE. + Note that the two last mechanisms are not very well scalable. The UE + user most probably does not want to type IPv6 RDNSS addresses + manually in his/her UE. The use of well-known addresses is briefly + discussed in section 5.3.4. + + It is seen that the mechanisms above most probably are not sufficient + for the 3GPP environment. IPv6 is intended to operate in a zero- + configuration manner, no matter what the underlying network + infrastructure is. Typically, the RDNSS address is needed to make an + IPv6 node operational - and the DNS configuration should be as simple + as the address autoconfiguration mechanism. It must also be noted + that there will be additional IP interfaces in some near future 3GPP + UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such + as PCO-IE [22]) do not work for those IP interfaces. In other words, + a good IPv6 DNS configuration mechanism should also work in a multi- + access network environment. + + From a 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (can be even + hundreds of millions in one operator's network), is automatic and + thus requires no user action. It is suggested to standardize a + lightweight, stateless mechanism that works in all network + environments. The solution could then be used for 3GPP, 3GPP2, WLAN + and other access network technologies. A light, stateless IPv6 DNS + configuration mechanism is thus not only needed in 3GPP networks, but + also 3GPP networks and UEs would certainly benefit from the new + mechanism. + +5.3.2 RA Extension + + Router Advertisement extension [8] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in the 3GPP UE + IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified in + the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs + + + +Jeong Expires November 6, 2005 [Page 19] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + and GGSNs + + In this solution, an IPv6-capable UE configures DNS information via + RA message sent by its default router (GGSN), i.e., RDNSS option for + recursive DNS server is included in the RA message. This solution is + easily scalable for a very large number of UEs. The operator can + configure the RDNSS addresses in the GGSN as a part of normal GGSN + configuration. The IPv6 RDNSS address is received in the Router + Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS + addresses can be avoided. + + If thinking about the cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3 Stateless DHCPv6 + + DHCPv6-based solution needs the implementation of Stateless DHCP [6] + and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the + operator's network. A possible configuration is such that the GGSN + works as a DHCP relay. + + Pros for Stateless DHCPv6-based solution are + + 1. Stateless DHCPv6 is a standardized mechanism. + + 2. DHCPv6 can be used for receiving other configuration information + than RDNSS addresses, e.g., SIP server addresses. + + 3. DHCPv6 works in different network environments. + + 4. When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + Some issues with DHCPv6 in 3GPP networks are listed below: + + 1. DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into a router + already existing, and that means one box more to be maintained. + + 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used), and + not automatically implemented in 3GPP IPv6 UEs. + + + + + +Jeong Expires November 6, 2005 [Page 20] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + 3. Scalability and reliability of DHCPv6 in very large 3GPP networks + (with tens or hundreds of millions of UEs) may be an issue, at + least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as a + router operating system, scalability and reliability is + comparable with other DNS configuration approaches. + + 4. It is sub-optimal to utilize the radio resources in 3GPP networks + for DHCPv6 messages if there is a simpler alternative available. + + * The use of Stateless DHCPv6 adds one round trip delay to the + case in which the UE can start transmitting data right after + the Router Advertisement. + + 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can + not automatically update the UE, see [23]. + + +5.3.4 Well-known Addresses + + Using well-known addresses is also a feasible and a light mechanism + for 3GPP UEs. Those well-known addresses can be preconfigured in the + UE software and the operator makes the corresponding configuration on + the network side. So this is a very easy mechanism for the UE, but + requires some configuration work in the network. When using well- + known addresses, UE forwards queries to any of the preconfigured + addresses. In the current proposal [9], IPv6 anycast addresses are + suggested. + +Note + + The IPv6 DNS configuration proposal based on the use of well-known + site-local addresses developed at the IPv6 Working Group was seen as + a feasible mechanism for 3GPP UEs, but opposition by some people in + the IETF and finally deprecating IPv6 site-local addresses made it + impossible to standardize it. Note that this mechanism is + implemented in some existing operating systems today (also in some + 3GPP UEs) as a last resort of IPv6 DNS configuration. + +5.3.5 Recommendations + + It is suggested that a lightweight, stateless DNS configuration + mechanism is specified as soon as possible. From a 3GPP UE and + network point of view, the Router Advertisement based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can get rid of using well-known site-local + addresses for IPv6 DNS configuration. + + + + +Jeong Expires November 6, 2005 [Page 21] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +5.4 Unmanaged Network + + There are 4 deployment scenarios of interest in unmanaged networks + [24]: + + 1. A gateway which does not provide IPv6 at all; + + 2. A dual-stack gateway connected to a dual-stack ISP; + + 3. A dual-stack gateway connected to an IPv4-only ISP; and + + 4. A gateway connected to an IPv6-only ISP. + + +5.4.1 Case A: Gateway does not provide IPv6 at all + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT, that need access to an + IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration + mechanism has to work over the tunnel, and the underlying tunneling + mechanism could be implementing NAT traversal. The tunnel server + assumes the role of a relay (both for DHCP and Well-known anycast + addresses approaches). + + RA-based mechanism is relatively straightforward in its operation, + assuming the tunnel server is also the IPv6 router emitting RAs. + Well-known anycast addresses approach seems also simple in operation + across the tunnel, but the deployment model using Well-known anycast + addresses in a tunneled environment is unclear or not well + understood. + +5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. Except that + Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the + DHCP server is stateful (maintains the state for clients). + +5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity by + managing tunnels, then it is also supposed to provide access to an + RDNSS. Like this, the tunnel for IPv6 connectivity originates from + the dual-stack gateway instead of the host. + + + + +Jeong Expires November 6, 2005 [Page 22] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +5.4.4 Case D: A gateway connected to an IPv6-only ISP + + This is similar to Case B. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 23] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +6. Security Considerations + + As security requirements depend solely on applications and are + different application by application, there can be no generic + requirement defined at IP or application layer for DNS. + + However, it should be noted that cryptographic security requires + configured secret information that full autoconfiguration and + cryptographic security are mutually exclusive. People insisting on + secure full autoconfiguration will get false security, false + autoconfiguration or both. + + In some deployment scenarios [19], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured through which application + specific configuration data, including those for DNS, can be securely + configured. It should be noted that if applications requiring + cryptographic security depend on DNS, the applications also require + cryptographic security to DNS. Therefore, the full autoconfiguration + of DNS is not acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be acceptable. + That is, with full autoconfiguration, which means there is no + cryptographic security for the autoconfiguration, it is already + assumed that the local environment is secure enough that the + information from the local autoconfiguration server has acceptable + security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, because + DNSSEC [29] needs the configuration and reconfiguration of clients at + root key roll-over [30][31]. Even if additional keys for secure key + roll-over are added at the initial configuration, they are as + vulnerable as the original keys to some forms of attacks, such as + social hacking. Another problem of using DNSSEC and + autoconfiguration together is that DNSSEC requires secure time, which + means secure communication with autoconfigured time servers, which + requires configured secret information. Therefore, in order that the + autoconfiguration may be secure, it requires configured secret + information. + + If DNSSEC [29] is used and the signatures are verified on the client + host, the misconfiguration of a DNS server may be simply denial of + service. Also, if local routing environment is not reliable, clients + may be directed to a false resolver with the same IP address as the + true one. + + + +Jeong Expires November 6, 2005 [Page 24] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +6.1 RA Option + + The security of RA option for RDNSS is the same as the ND protocol + security [3][8]. The RA option does not add any new vulnerability. + + It should be noted that the vulnerability of ND is not worse and is a + subset of the attacks that any node attached to a LAN can do + independently of ND. A malicious node on a LAN can promiscuously + receive packets for any router's MAC address and send packets with + the router's MAC address as the source MAC address in the L2 header. + As a result, the L2 switches send packets addressed to the router to + the malicious node. Also, this attack can send redirects that tell + the hosts to send their traffic somewhere else. The malicious node + can send unsolicited RA or NA replies, answer RS or NS requests, etc. + All of this can be done independently of implementing ND. Therefore, + the RA option for RDNSS does not add to the vulnerability. + + Security issues regarding the ND protocol were discussed at IETF SEND + (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND + security has been published [14]. + +6.2 DHCPv6 Option + + The DNS Recursive Name Server option may be used by an intruder DHCP + server to cause DHCP clients to send DNS queries to an intruder DNS + recursive name server [7]. The results of these misdirected DNS + queries may be used to spoof DNS names. + + To avoid attacks through the DNS Recursive Name Server option, the + DHCP client SHOULD require DHCP authentication (see section + "Authentication of DHCP messages" in RFC 3315 [5]) before installing + a list of DNS recursive name servers obtained through authenticated + DHCP. + +6.3 Well-known Anycast Addresses + + Well-known anycast addresses does not require configuration security + since there is no protocol [9]. + + The DNS server with the preconfigured addresses are still reasonably + reliable, if local environment is reasonably secure, that is, there + is no active attackers receiving queries to the anycast addresses of + the servers and reply to them. + + + + + + + + +Jeong Expires November 6, 2005 [Page 25] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +7. Contributors + + Ralph Droms + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxboro, MA 01719 + US + + Phone: +1 978 936 1674 + Email: rdroms@cisco.com + + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + US + + Phone: +1 650 625 2004 + Email: bob.hinden@nokia.com + + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + US + + Email: Ted.Lemon@nominum.com + + + Masataka Ohta + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + Email: mohta@necom830.hpcl.titech.ac.jp + + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 + Korea + + + + +Jeong Expires November 6, 2005 [Page 26] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + Phone: +82 31 200 4508 + Email: soohong.park@samsung.com + + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + US + + Email: satapati@cisco.com + + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720, TAMPERE + Finland + + Phone: +358 7180 48372 + Email: juha.wiljakka@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 27] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +8. Acknowledgements + + This draft has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. + Also, Tony Bonanno proofread this draft. The authors appreciate + their contribution. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 28] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +9. References + +9.1 Normative References + + [1] Bradner, S., "IETF Rights in Contributions", RFC 3667, + February 2004. + + [2] Bradner, S., "Intellectual Property Rights in IETF Technology", + RFC 3668, February 2004. + + [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [4] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) + Service for IPv6", RFC 3736, April 2004. + + [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + +9.2 Informative References + + [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS + Discovery based on Router Advertisement", + draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress), + February 2005. + + [9] Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01.txt (Work in Progress), + February 2004. + + [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time + Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in + Progress), January 2005. + + [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6 + + + +Jeong Expires November 6, 2005 [Page 29] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + into ISP Networks", RFC 4029, March 2005. + + [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971, + March 2005. + + [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios", + draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress), + July 2004. + + [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP + Standards", RFC 3314, September 2002. + + [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks", + RFC 3574, August 2003. + + [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in + Progress), October 2004. + + [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering + Requirements for Stateless DHCPv6", + draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in + Progress), October 2004. + + [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition + Scenarios", RFC 3750, April 2004. + + [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) Specifications", + March 1999. + + [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: High-speed + Physical Layer in the 5 GHZ Band", September 1999. + + + +Jeong Expires November 6, 2005 [Page 30] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + + [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) specifications: Higher-Speed + Physical Layer Extension in the 2.4 GHz Band", September 1999. + + [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access + Control (MAC) and Physical Layer (PHY) specifications: Further + Higher Data Rate Extension in the 2.4 GHz Band", April 2003. + + [29] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in + Progress), December 2004. + + [31] Guette, G. and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", + draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in + Progress), January 2005. + + [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M + and O Flags of IPv6 Router Advertisement", + draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress), + March 2005. + + +Author's Address + + Jaehoon Paul Jeong (editor) + ETRI/Department of Computer Science and Engineering + University of Minnesota + 117 Pleasant Street SE + Minneapolis, MN 55455 + US + + Phone: +1 651 587 7774 + Fax: +1 612 625 2002 + Email: jjeong@cs.umn.edu + URI: http://www.cs.umn.edu/~jjeong/ + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 31] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +Appendix A. Link-layer Multicast Acknowledgements for RA Option + + One benefit of an RA option [8] is to be able to multicast the + advertisements, reducing the need for duplicated unicast + communications. + + However, some link-layers may not support this as well as others. + Consider, for example, WLAN networks where multicast is unreliable. + The unreliability problem is caused by lack of ACK for multicast, + especially on the path from the Access Point (AP) to the Station + (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11 + a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on + the path from the AP to the STA, but acknowledged in the reverse + direction from the STA to the AP [25]. For example, when a router is + placed at wired network connected to an AP, a host may sometimes not + receive RA message advertised through the AP. Therefore, the RA + option solution might not work well on a congested medium that uses + unreliable multicast for RA. + + The fact that this problem has not been addressed in Neighbor + Discovery [3] indicates that the extra link-layer acknowledgements + have not been considered a serious problem till now. + + A possible mitigation technique could be to map all-nodes link- local + multicast address to the link-layer broadcast address, and to rely on + the ND retransmissions for message delivery in order to achieve more + reliability. + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Expires November 6, 2005 [Page 32] + +Internet-Draft IPv6 Host Configuration of DNS Server May 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Jeong Expires November 6, 2005 [Page 33] + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt new file mode 100644 index 0000000..1276f9f --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt @@ -0,0 +1,1682 @@ + + + + +DNS Operations WG A. Durand +Internet-Draft SUN Microsystems, Inc. +Expires: January 17, 2006 J. Ihren + Autonomica + P. Savola + CSC/FUNET + July 16, 2005 + + + Operational Considerations and Issues with IPv6 DNS + draft-ietf-dnsop-ipv6-dns-issues-11.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 17, 2006. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehaviour, + recommendations and considerations on how to perform DNS naming for + service provisioning and for DNS resolver IPv6 support, + + + +Durand, et al. Expires January 17, 2006 [Page 1] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + considerations for DNS updates for both the forward and reverse + trees, and miscellaneous issues. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 + 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 + 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 + 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 + 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 + 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 + 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 + 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 + 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 + 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 + 4. Recommendations for Service Provisioning using DNS . . . . . . 7 + 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 + 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 + 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 + 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 + 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10 + 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10 + 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 + 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 13 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Security Considerations . . . . . . . . . . . . . . . . . . 20 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 + + + +Durand, et al. Expires January 17, 2006 [Page 2] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 + A. Unique Local Addressing Considerations for DNS . . . . . . . . 25 + B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25 + B.1 Description of Additional Data Scenarios . . . . . . . . . 26 + B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27 + B.3 Discussion of the Potential Problems . . . . . . . . . . . 28 + Intellectual Property and Copyright Statements . . . . . . . . 30 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires January 17, 2006 [Page 3] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +1. Introduction + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience with IPv4 DNS. + + The purpose of this document is to give information about various + issues and considerations related to DNS operations with IPv6; it is + not meant to be a normative specification or standard for IPv6 DNS. + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the DNS, how transport protocols and + resource records (don't) relate, and what IPv4/IPv6 name space + fragmentation means and how to avoid it; all of these are described + at more length in other documents. + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviours which have a varying effect on the use + of IPv6 records with DNS. The fourth section lists recommendations + and considerations for provisioning services with DNS. The fifth + section in turn looks at recommendations and considerations about + providing IPv6 support in the resolvers. The sixth and seventh + sections describe considerations with forward and reverse DNS + updates, respectively. The eighth section introduces several + miscellaneous IPv6 issues relating to DNS for which no better place + has been found in this memo. Appendix A looks briefly at the + requirements for unique local addressing. + +1.1 Representing IPv6 Addresses in DNS Records + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + PTR records in the nibble format under the ip6.arpa. tree. See + [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] + for background information. + + In particular one should note that the use of A6 records in the + forward tree or Bitlabels in the reverse tree is not recommended + [RFC3363]. Using DNAME records is not recommended in the reverse + tree in conjunction with A6 records; the document did not mean to + take a stance on any other use of DNAME records [RFC3364]. + +1.2 Independence of DNS Transport and DNS Records + + DNS has been designed to present a single, globally unique name space + [RFC2826]. This property should be maintained, as described here and + + + +Durand, et al. Expires January 17, 2006 [Page 4] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + in Section 1.3. + + The IP version used to transport the DNS queries and responses is + independent of the records being queried: AAAA records can be queried + over IPv4, and A records over IPv6. The DNS servers must not make + any assumptions about what data to return for Answer and Authority + sections based on the underlying transport used in a query. + + However, there is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + at all). + + As stated in [RFC3596]: + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + +1.3 Avoiding IPv4/IPv6 Name Space Fragmentation + + To avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines [RFC3901] for more information. + +1.4 Query Type '*' and A/AAAA Records + + QTYPE=* is typically only used for debugging or management purposes; + it is worth keeping in mind that QTYPE=* ("ANY" queries) only return + any available RRsets, not *all* the RRsets, because the caches do not + necessarily have all the RRsets and have no way of guaranteeing that + they have all the RRsets. Therefore, to get both A and AAAA records + reliably, two separate queries must be made. + +2. DNS Considerations about Special IPv6 Addresses + + There are a couple of IPv6 address types which are somewhat special; + these are considered here. + + + + + + +Durand, et al. Expires January 17, 2006 [Page 5] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +2.1 Limited-scope Addresses + + The IPv6 addressing architecture [RFC3513] includes two kinds of + local-use addresses: link-local (fe80::/10) and site-local + (fec0::/10). The site-local addresses have been deprecated [RFC3879] + but are discussed with unique local addresses in Appendix A. + + Link-local addresses should never be published in DNS (whether in + forward or reverse tree), because they have only local (to the + connected link) significance [I-D.durand-dnsop-dont-publish]. + +2.2 Temporary Addresses + + Temporary addresses defined in RFC3041 [RFC3041] (sometimes called + "privacy addresses") use a random number as the interface identifier. + Having DNS AAAA records that are updated to always contain the + current value of a node's temporary address would defeat the purpose + of the mechanism and is not recommended. However, it would still be + possible to return a non-identifiable name (e.g., the IPv6 address in + hexadecimal format), as described in [RFC3041]. + +2.3 6to4 Addresses + + 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps + a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + + If the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of possible ways to do so. + + The main proposal [I-D.huston-6to4-reverse-dns] aims to design an + autonomous reverse-delegation system that anyone being capable of + communicating using a specific 6to4 address would be able to set up a + reverse delegation to the corresponding 6to4 prefix. This could be + deployed by e.g., Regional Internet Registries (RIRs). This is a + practical solution, but may have some scalability concerns. + +2.4 Other Transition Mechanisms + + 6to4 is mentioned as a case of an IPv6 transition mechanism requiring + special considerations. In general, mechanisms which include a + special prefix may need a custom solution; otherwise, for example + when IPv4 address is embedded as the suffix or not embedded at all, + special solutions are likely not needed. + + Note that it does not seem feasible to provide reverse DNS with + another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops- + teredo]; this is because the IPv6 address is based on the IPv4 + address and UDP port of the current NAT mapping which is likely to be + + + +Durand, et al. Expires January 17, 2006 [Page 6] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + relatively short-lived. + +3. Observed DNS Implementation Misbehaviour + + Several classes of misbehaviour in DNS servers, load-balancers and + resolvers have been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehaviour are extremely severe in IPv6 environments and + deserve to be mentioned. + +3.1 Misbehaviour of DNS Servers and Load-balancers + + There are several classes of misbehaviour in certain DNS servers and + load-balancers which have been noticed and documented [RFC4074]: some + implementations silently drop queries for unimplemented DNS records + types, or provide wrong answers to such queries (instead of a proper + negative reply). While typically these issues are not limited to + AAAA records, the problems are aggravated by the fact that AAAA + records are being queried instead of (mainly) A records. + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- + if the first query is never responded to (instead of properly + returning a negative answer), significant timeouts will occur. + + In consequence, this is an enormous problem for IPv6 deployments, and + in some cases, IPv6 support in the software has even been disabled + due to these problems. + + The solution is to fix or retire those misbehaving implementations, + but that is likely not going to be effective. There are some + possible ways to mitigate the problem, e.g., by performing the + lookups somewhat in parallel and reducing the timeout as long as at + least one answer has been received; but such methods remain to be + investigated; slightly more on this is included in Section 5. + +3.2 Misbehaviour of DNS Resolvers + + Several classes of misbehaviour have also been noticed in DNS + resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem + to directly impair IPv6 use, and are only referred to for + completeness. + +4. Recommendations for Service Provisioning using DNS + + When names are added in the DNS to facilitate a service, there are + + + +Durand, et al. Expires January 17, 2006 [Page 7] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + several general guidelines to consider to be able to do it as + smoothly as possible. + +4.1 Use of Service Names instead of Node Names + + It makes sense to keep information about separate services logically + separate in the DNS by using a different DNS hostname for each + service. There are several reasons for doing this, for example: + + o It allows more flexibility and ease for migration of (only a part + of) services from one node to another, + + o It allows configuring different properties (e.g., TTL) for each + service, and + + o It allows deciding separately for each service whether to publish + the IPv6 addresses or not (in cases where some services are more + IPv6-ready than others). + + Using SRV records [RFC2782] would avoid these problems. + Unfortunately, those are not sufficiently widely used to be + applicable in most cases. Hence an operation technique is to use + service names instead of node names (or, "hostnames"). This + operational technique is not specific to IPv6, but required to + understand the considerations described in Section 4.2 and + Section 4.3. + + For example, assume a node named "pobox.example.com" provides both + SMTP and IMAP service. Instead of configuring the MX records to + point at "pobox.example.com", and configuring the mail clients to + look up the mail via IMAP from "pobox.example.com", one could use + e.g., "smtp.example.com" for SMTP (for both message submission and + mail relaying between SMTP servers) and "imap.example.com" for IMAP. + Note that in the specific case of SMTP relaying, the server itself + must typically also be configured to know all its names to ensure + loops do not occur. DNS can provide a layer of indirection between + service names and where the service actually is, and using which + addresses. (Obviously, when wanting to reach a specific node, one + should use the hostname rather than a service name.) + +4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + The service naming can be achieved in basically two ways: when a + service is named "service.example.com" for IPv4, the IPv6-enabled + service could either be added to "service.example.com", or added + separately under a different name, e.g., in a sub-domain, like, + "service.ipv6.example.com". + + + + +Durand, et al. Expires January 17, 2006 [Page 8] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + These two methods have different characteristics. Using a different + name allows for easier service piloting, minimizing the disturbance + to the "regular" users of IPv4 service; however, the service would + not be used transparently, without the user/application explicitly + finding it and asking for it -- which would be a disadvantage in most + cases. When the different name is under a sub-domain, if the + services are deployed within a restricted network (e.g., inside an + enterprise), it's possible to prefer them transparently, at least to + a degree, by modifying the DNS search path; however, this is a + suboptimal solution. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (see + Section 4.3 for more). + + In most cases, it makes sense to pilot or test a service using + separate service names, and move to the use of the same name when + confident enough that the service level will not degrade for the + users unaware of IPv6. + +4.3 Adding the Records Only when Fully IPv6-enabled + + The recommendation is that AAAA records for a service should not be + added to the DNS until all of following are true: + + 1. The address is assigned to the interface on the node. + + 2. The address is configured on the interface. + + 3. The interface is on a link which is connected to the IPv6 + infrastructure. + + In addition, if the AAAA record is added for the node, instead of + service as recommended, all the services of the node should be IPv6- + enabled prior to adding the resource record. + + For example, if an IPv6 node is isolated from an IPv6 perspective + (e.g., it is not connected to IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + Consider the case of two dual-stack nodes, which both have IPv6 + enabled, but the server does not have (global) IPv6 connectivity. As + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would have been unsuccessful, is even attempted. + + The issues are not always so black-and-white. Usually it's important + that the service offered using both protocols is of roughly equal + quality, using the appropriate metrics for the service (e.g., + + + +Durand, et al. Expires January 17, 2006 [Page 9] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + latency, throughput, low packet loss, general reliability, etc.) -- + this is typically very important especially for interactive or real- + time services. In many cases, the quality of IPv6 connectivity may + not yet be equal to that of IPv4, at least globally -- this has to be + taken into consideration when enabling services. + +4.4 The Use of TTL for IPv4 and IPv6 RRs + + The behaviour of DNS caching when different TTL values are used for + different RRsets of the same name calls for explicit discussion. For + example, let's consider two unrelated zone fragments: + + example.com. 300 IN MX foo.example.com. + foo.example.com. 300 IN A 192.0.2.1 + foo.example.com. 100 IN AAAA 2001:db8::1 + + ... + + child.example.com. 300 IN NS ns.child.example.com. + ns.child.example.com. 300 IN A 192.0.2.1 + ns.child.example.com. 100 IN AAAA 2001:db8::1 + + In the former case, we have "courtesy" additional data; in the + latter, we have "critical" additional data. See more extensive + background discussion of additional data handling in Appendix B. + +4.4.1 TTL With Courtesy Additional Data + + When a caching resolver asks for the MX record of example.com, it + gets back "foo.example.com". It may also get back either one or both + of the A and AAAA records in the additional section. The resolver + must explicitly query for both A and AAAA records [RFC2821]. + + After 100 seconds, the AAAA record is removed from the cache(s) + because its TTL expired. It could be argued to be useful for the + caching resolvers to discard the A record when the shorter TTL (in + this case, for the AAAA record) expires; this would avoid the + situation where there would be a window of 200 seconds when + incomplete information is returned from the cache. Further argument + for discarding is that in the normal operation, the TTL values are so + high that very likely the incurred additional queries would not be + noticeable, compared to the obtained performance optimization. The + behaviour in this scenario is unspecified. + +4.4.2 TTL With Critical Additional Data + + The difference to courtesy additional data is that the A/AAAA records + served by the parent zone cannot be queried explicitly. Therefore + + + +Durand, et al. Expires January 17, 2006 [Page 10] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + after 100 seconds the AAAA record is removed from the cache(s), but + the A record remains. Queries for the remaining 200 seconds + (provided that there are no further queries from the parent which + could refresh the caches) only return the A record, leading to a + potential opererational situation with unreachable servers. + + Similar cache flushing strategies apply in this scenario; the record. + +4.5 IPv6 Transport Guidelines for DNS Servers + + As described in Section 1.3 and [RFC3901], there should continue to + be at least one authoritative IPv4 DNS server for every zone, even if + the zone has only IPv6 records. (Note that obviously, having more + servers with robust connectivity would be preferable, but this is the + minimum recommendation; also see [RFC2182].) + +5. Recommendations for DNS Resolver IPv6 Support + + When IPv6 is enabled on a node, there are several things to consider + to ensure that the process is as smooth as possible. + +5.1 DNS Lookups May Query IPv6 Records Prematurely + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavours: + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version which supports IPv6. + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + 3. The system library might implement a toggle which would apply + some heuristics to the "IPv6-readiness" of the node before + starting to perform queries; for example, it could check whether + only link-local IPv6 address(es) exists, or if at least one + global IPv6 address exists. + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + + + +Durand, et al. Expires January 17, 2006 [Page 11] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + received to the AAAA query. Considering the misbehaviour of DNS + servers and load-balancers, as described in Section 3.1, the look-up + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result (immediate parallelism might be unoptimal, at least without + information sharing between the look-up threads, as that would + probably lead to duplicate non-cached delegation chain lookups). + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records even when the node + does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. + In some cases, the implementation may attempt to connect or send a + datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], + incurring very long protocol timeouts, instead of quickly failing + back to IPv4. + + Now, we can consider the issues specific to each of the three + possibilities: + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + application is programmed properly, the application can fall + gracefully back to IPv4 [RFC4038]. + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet; similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first which may typically lead to long timeouts. + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services which getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That is, + performing DNS lookups only when a non-link-local address has been + configured on any interface could be beneficial -- this would be an + indication that either the address has been configured either from a + router advertisement, DHCPv6 [RFC3315], or manually. Each would + + + +Durand, et al. Expires January 17, 2006 [Page 12] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + indicate at least some form of IPv6 connectivity, even though there + would not be guarantees of it. + + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. + +5.2 Obtaining a List of DNS Recursive Resolvers + + In scenarios where DHCPv6 is available, a host can discover a list of + DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" + option [RFC3646]. This option can be passed to a host through a + subset of DHCPv6 [RFC3736]. + + The IETF is considering the development of alternative mechanisms for + obtaining the list of DNS recursive name servers when DHCPv6 is + unavailable or inappropriate. No decision about taking on this + development work has been reached as of this writing (Aug 2004) + [I-D.ietf-dnsop-ipv6-dns-configuration]. + + In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms + under consideration for development include the use of well-known + addresses [I-D.ohta-preconfigured-dns] and the use of Router + Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns- + discovery]. + + Note that even though IPv6 DNS resolver discovery is a recommended + procedure, it is not required for dual-stack nodes in dual-stack + networks as IPv6 DNS records can be queried over IPv4 as well as + IPv6. Obviously, nodes which are meant to function without manual + configuration in IPv6-only networks must implement the DNS resolver + discovery function. + +5.3 IPv6 Transport Guidelines for Resolvers + + As described in Section 1.3 and [RFC3901], the recursive resolvers + should be IPv4-only or dual-stack to be able to reach any IPv4-only + DNS server. Note that this requirement is also fulfilled by an IPv6- + only stub resolver pointing to a dual-stack recursive DNS resolver. + +6. Considerations about Forward DNS Updating + + While the topic of how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + IPv6, it should be considered especially due to the advent of + Stateless Address Autoconfiguration [RFC2462]. + + Typically forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can often be assumed to "own" a + + + +Durand, et al. Expires January 17, 2006 [Page 13] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + certain DNS name -- and we can create a form of security relationship + with the DNS name and the node which is allowed to update it to point + to a new address. + + A more complex form of DNS updates -- adding a whole new name into a + DNS zone, instead of updating an existing name -- is considered out + of scope for this memo as it could require zone-wide authentication. + Adding a new name in the forward zone is a problem which is still + being explored with IPv4, and IPv6 does not seem to add much new in + that area. + +6.1 Manual or Custom DNS Updates + + The DNS mappings can also be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + +6.2 Dynamic DNS + + Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized + mechanism for dynamically updating the DNS. It works equally well + with stateless address autoconfiguration (SLAAC), DHCPv6 or manual + address configuration. It is important to consider how each of these + behave if IP address-based authentication, instead of stronger + mechanisms [RFC3007], was used in the updates. + + 1. manual addresses are static and can be configured + + 2. DHCPv6 addresses could be reasonably static or dynamic, depending + on the deployment, and could or could not be configured on the + DNS server for the long term + + 3. SLAAC addresses are typically stable for a long time, but could + require work to be configured and maintained. + + As relying on IP addresses for Dynamic DNS is rather insecure at + best, stronger authentication should always be used; however, this + requires that the authorization keying will be explicitly configured + using unspecified operational methods. + + Note that with DHCP it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + + + +Durand, et al. Expires January 17, 2006 [Page 14] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + host should not be able to state that its name is "www.example.com"). + DHCP-initiated DDNS updates have been extensively described in + [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and + [I-D.ietf-dnsext-dhcid-rr]. + + The nodes must somehow be configured with the information about the + servers where they will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authoritative name servers + for the hostname; the second must be configured explicitly unless one + chooses to trust the IP address-based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g., at install time. + + Care should be observed when updating the addresses not to use longer + TTLs for addresses than are preferred lifetimes for the addresses, so + that if the node is renumbered in a managed fashion, the amount of + stale DNS information is kept to the minimum. That is, if the + preferred lifetime of an address expires, the TTL of the record needs + be modified unless it was already done before the expiration. For + better flexibility, the DNS TTL should be much shorter (e.g., a half + or a third) than the lifetime of an address; that way, the node can + start lowering the DNS TTL if it seems like the address has not been + renewed/refreshed in a while. Some discussion on how an + administrator could manage the DNS TTL is included in [I-D.ietf- + v6ops-renumbering-procedure]; this could be applied to (smart) hosts + as well. + +7. Considerations about Reverse DNS Updating + + Updating the reverse DNS zone may be difficult because of the split + authority over an address. However, first we have to consider the + applicability of reverse DNS in the first place. + +7.1 Applicability of Reverse DNS + + Today, some applications use reverse DNS to either look up some hints + about the topological information associated with an address (e.g. + resolving web server access logs), or as a weak form of a security + check, to get a feel whether the user's network administrator has + "authorized" the use of the address (on the premises that adding a + reverse record for an address would signal some form of + authorization). + + One additional, maybe slightly more useful usage is ensuring that the + reverse and forward DNS contents match (by looking up the pointer to + the name by the IP address from the reverse tree, and ensuring that a + + + +Durand, et al. Expires January 17, 2006 [Page 15] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + record under the name in the forward tree points to the IP address) + and correspond to a configured name or domain. As a security check, + it is typically accompanied by other mechanisms, such as a user/ + password login; the main purpose of the reverse+forward DNS check is + to weed out the majority of unauthorized users, and if someone + managed to bypass the checks, he would still need to authenticate + "properly". + + It may also be desirable to store IPsec keying material corresponding + to an IP address in the reverse DNS, as justified and described in + [RFC4025]. + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + which use it as a generic authorization (in the sense that a record + exists at all) should be modified as soon as possible to avoid such + lookups completely. + + The applicability is discussed at more length in [I-D.ietf-dnsop- + inaddr-required]. + +7.2 Manual or Custom DNS Updates + + Reverse DNS can of course be updated using manual or custom methods. + These are not further described here, except for one special case. + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + As a concrete example, a site (or the site's ISP) could configure the + reverses of the prefix 2001:db8:f00::/48 to point to one name using a + wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR + site.example.com." Naturally, such a name could not be verified from + the forward DNS, but would at least provide some form of "topological + information" or "weak authorization" if that is really considered to + be useful. Note that this is not actually updating the DNS as such, + as the whole point is to avoid DNS updates completely by manually + configuring a generic name. + +7.3 DDNS with Stateless Address Autoconfiguration + + Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in + some regard, while being more difficult in another, as described + below. + + The address space administrator decides whether the hosts are trusted + to update their reverse DNS records or not. If they are trusted and + + + +Durand, et al. Expires January 17, 2006 [Page 16] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + deployed at the same site (e.g., not across the Internet), a simple + address-based authorization is typically sufficient (i.e., check that + the DNS update is done from the same IP address as the record being + updated); stronger security can also be used [RFC3007]. If they + aren't allowed to update the reverses, no update can occur. However, + such address-based update authorization operationally requires that + ingress filtering [RFC3704] has been set up at the border of the site + where the updates occur, and as close to the updater as possible. + + Address-based authorization is simpler with reverse DNS (as there is + a connection between the record and the address) than with forward + DNS. However, when a stronger form of security is used, forward DNS + updates are simpler to manage because the host can be assumed to have + an association with the domain. Note that the user may roam to + different networks, and does not necessarily have any association + with the owner of that address space -- so, assuming stronger form of + authorization for reverse DNS updates than an address association is + generally infeasible. + + Moreover, the reverse zones must be cleaned up by an unspecified + janitorial process: the node does not typically know a priori that it + will be disconnected, and cannot send a DNS update using the correct + source address to remove a record. + + A problem with defining the clean-up process is that it is difficult + to ensure that a specific IP address and the corresponding record are + no longer being used. Considering the huge address space, and the + unlikelihood of collision within 64 bits of the interface + identifiers, a process which would remove the record after no traffic + has been seen from a node in a long period of time (e.g., a month or + year) might be one possible approach. + + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in + Section 6.2. One way to automate this is looking up the DNS server + authoritative (e.g., through SOA record) for the IP address being + updated, but the security material (unless the IP address-based + authorization is trusted) must also be established by some other + means. + + One should note that Cryptographically Generated Addresses [RFC3972] + (CGAs) may require a slightly different kind of treatment. CGAs are + addresses where the interface identifier is calculated from a public + key, a modifier (used as a nonce), the subnet prefix, and other data. + Depending on the usage profile, CGAs might or might not be changed + periodically due to e.g., privacy reasons. As the CGA address is not + predicatable, a reverse record can only reasonably be inserted in the + DNS by the node which generates the address. + + + +Durand, et al. Expires January 17, 2006 [Page 17] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +7.4 DDNS with DHCP + + With DHCPv4, the reverse DNS name is typically already inserted to + the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One + can assume similar practice may become commonplace with DHCPv6 as + well; all such mappings would be pre-configured, and would require no + updating. + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact that typically one must update + a reverse DNS record instead of inserting one (if an address + assignment policy that reassigns disused addresses is adopted) and + updating a record seems like a slightly more difficult thing to + secure. However, it is yet uncertain how DHCPv6 is going to be used + for address assignment. + + Note that when using DHCP, either the host or the DHCP server could + perform the DNS updates; see the implications in Section 6.2. + + If disused addresses were to be reassigned, host-based DDNS reverse + updates would need policy considerations for DNS record modification, + as noted above. On the other hand, if disused address were not to be + assigned, host-based DNS reverse updates would have similar + considerations as SLAAC in Section 7.3. Server-based updates have + similar properties except that the janitorial process could be + integrated with DHCP address assignment. + +7.5 DDNS with Dynamic Prefix Delegation + + In cases where a prefix, instead of an address, is being used and + updated, one should consider what is the location of the server where + DDNS updates are made. That is, where the DNS server is located: + + 1. At the same organization as the prefix delegator. + + 2. At the site where the prefixes are delegated to. In this case, + the authority of the DNS reverse zone corresponding to the + delegated prefix is also delegated to the site. + + 3. Elsewhere; this implies a relationship between the site and where + DNS server is located, and such a relationship should be rather + straightforward to secure as well. Like in the previous case, + the authority of the DNS reverse zone is also delegated. + + In the first case, managing the reverse DNS (delegation) is simpler + as the DNS server and the prefix delegator are in the same + administrative domain (as there is no need to delegate anything at + all); alternatively, the prefix delegator might forgo DDNS reverse + + + +Durand, et al. Expires January 17, 2006 [Page 18] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + capability altogether, and use e.g., wildcard records (as described + in Section 7.2). In the other cases, it can be slighly more + difficult, particularly as the site will have to configure the DNS + server to be authoritative for the delegated reverse zone, implying + automatic configuration of the DNS server -- as the prefix may be + dynamic. + + Managing the DDNS reverse updates is typically simple in the second + case, as the updated server is located at the local site, and + arguably IP address-based authentication could be sufficient (or if + not, setting up security relationships would be simpler). As there + is an explicit (security) relationship between the parties in the + third case, setting up the security relationships to allow reverse + DDNS updates should be rather straightforward as well (but IP + address-based authentication might not be acceptable). In the first + case, however, setting up and managing such relationships might be a + lot more difficult. + +8. Miscellaneous DNS Considerations + + This section describes miscellaneous considerations about DNS which + seem related to IPv6, for which no better place has been found in + this document. + +8.1 NAT-PT with DNS-ALG + + The DNS-ALG component of NAT-PT mangles A records to look like AAAA + records to the IPv6-only nodes. Numerous problems have been + identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is + a strong reason not to use NAT-PT in the first place. + +8.2 Renumbering Procedures and Applications' Use of DNS + + One of the most difficult problems of systematic IP address + renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that + an application which looks up a DNS name disregards information such + as TTL, and uses the result obtained from DNS as long as it happens + to be stored in the memory of the application. For applications + which run for a long time, this could be days, weeks or even months; + some applications may be clever enough to organize the data + structures and functions in such a manner that look-ups get refreshed + now and then. + + While the issue appears to have a clear solution, "fix the + applications", practically this is not reasonable immediate advice; + the TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs and + libraries"), and a lot more analysis is needed on how to practically + + + +Durand, et al. Expires January 17, 2006 [Page 19] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + go about to achieve the ultimate goal of avoiding using the names + longer than expected. + +9. Acknowledgements + + Some recommendations (Section 4.3, Section 5.1) about IPv6 service + provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik + Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided + useful feedback and improvements. Scott Rose, Rob Austein, Masataka + Ohta, and Mark Andrews helped in clarifying the issues regarding + additional data and the use of TTL. Jefsey Morfin, Ralph Droms, + Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and + Rob Austein provided useful feedback during the WG last call. Thomas + Narten provided extensive feedback during the IESG evaluation. + +10. Security Considerations + + This document reviews the operational procedures for IPv6 DNS + operations and does not have security considerations in itself. + + However, it is worth noting that in particular with Dynamic DNS + Updates, security models based on the source address validation are + very weak and cannot be recommended -- they could only be considered + in the environments where ingress filtering [RFC3704] has been + deployed. On the other hand, it should be noted that setting up an + authorization mechanism (e.g., a shared secret, or public-private + keys) between a node and the DNS server has to be done manually, and + may require quite a bit of time and expertise. + + To re-emphasize what was already stated, the reverse+forward DNS + check provides very weak security at best, and the only + (questionable) security-related use for them may be in conjunction + with other mechanisms when authenticating a user. + +11. References + +11.1 Normative References + + [I-D.ietf-dnsop-ipv6-dns-configuration] + Jeong, J., "IPv6 Host Configuration of DNS Server + Information Approaches", + draft-ietf-dnsop-ipv6-dns-configuration-06 (work in + progress), May 2005. + + [I-D.ietf-ipv6-unique-local-addr] + Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in + progress), January 2005. + + + +Durand, et al. Expires January 17, 2006 [Page 20] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + [I-D.ietf-v6ops-renumbering-procedure] + Baker, F., "Procedures for Renumbering an IPv6 Network + without a Flag Day", + draft-ietf-v6ops-renumbering-procedure-05 (work in + progress), March 2005. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection + and Operation of Secondary DNS Servers", BCP 16, RFC 2182, + July 1997. + + [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 3041, + January 2001. + + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. + + [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) + + + +Durand, et al. Expires January 17, 2006 [Page 21] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + Addresses in the Domain Name System (DNS)", RFC 3363, + August 2002. + + [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) + Support for Internet Protocol version 6 (IPv6)", RFC 3364, + August 2002. + + [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational + Guidelines", BCP 91, RFC 3901, September 2004. + + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. + Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. + + [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against + DNS Queries for IPv6 Addresses", RFC 4074, May 2005. + +11.2 Informative References + + [I-D.durand-dnsop-dont-publish] + Durand, A. and T. Chown, "To publish, or not to publish, + that is the question.", draft-durand-dnsop-dont-publish-00 + (work in progress), February 2005. + + [I-D.huitema-v6ops-teredo] + Huitema, C., "Teredo: Tunneling IPv6 over UDP through + NATs", draft-huitema-v6ops-teredo-05 (work in progress), + April 2005. + + [I-D.huston-6to4-reverse-dns] + Huston, G., "6to4 Reverse DNS Delegation", + + + +Durand, et al. Expires January 17, 2006 [Page 22] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + draft-huston-6to4-reverse-dns-03 (work in progress), + October 2004. + + [I-D.ietf-dhc-ddns-resolution] + Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among + DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in + progress), June 2005. + + [I-D.ietf-dhc-fqdn-option] + Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", + draft-ietf-dhc-fqdn-option-10 (work in progress), + February 2005. + + [I-D.ietf-dnsext-dhcid-rr] + Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for + encoding DHCP information (DHCID RR)", + draft-ietf-dnsext-dhcid-rr-09 (work in progress), + February 2005. + + [I-D.ietf-dnsop-bad-dns-res] + Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in + progress), October 2004. + + [I-D.ietf-dnsop-inaddr-required] + Senie, D., "Encouraging the use of DNS IN-ADDR Mapping", + draft-ietf-dnsop-inaddr-required-06 (work in progress), + February 2005. + + [I-D.ietf-v6ops-3gpp-analysis] + Wiljakka, J., "Analysis on IPv6 Transition in 3GPP + Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in + progress), October 2004. + + [I-D.ietf-v6ops-mech-v2] + Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms + for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 + (work in progress), March 2005. + + [I-D.ietf-v6ops-natpt-to-exprmntl] + Aoun, C. and E. Davies, "Reasons to Move NAT-PT to + Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work + in progress), July 2005. + + [I-D.ietf-v6ops-onlinkassumption] + Roy, S., "IPv6 Neighbor Discovery On-Link Assumption + Considered Harmful", draft-ietf-v6ops-onlinkassumption-03 + (work in progress), May 2005. + + + +Durand, et al. Expires January 17, 2006 [Page 23] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + [I-D.ietf-v6ops-v6onbydefault] + Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack + IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 + (work in progress), July 2004. + + [I-D.jeong-dnsop-ipv6-dns-discovery] + Jeong, J., "IPv6 DNS Configuration based on Router + Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04 + (work in progress), February 2005. + + [I-D.ohta-preconfigured-dns] + Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-01 (work in progress), + February 2004. + + [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address + Translation - Protocol Translation (NAT-PT)", RFC 2766, + February 2000. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [RFC2826] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, March 2005. + + +Authors' Addresses + + Alain Durand + SUN Microsystems, Inc. + 17 Network circle UMPL17-202 + Menlo Park, CA 94025 + USA + + Email: Alain.Durand@sun.com + + + + + + +Durand, et al. Expires January 17, 2006 [Page 24] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + Email: johani@autonomica.se + + + Pekka Savola + CSC/FUNET + Espoo + Finland + + Email: psavola@funet.fi + +Appendix A. Unique Local Addressing Considerations for DNS + + Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have + replaced the now-deprecated site-local addresses [RFC3879]. From the + perspective of the DNS, the locally generated unique local addresses + (LUL) and site-local addresses have similar properties. + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + To actually use local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that local addresses must not be published in the public DNS. + + To faciliate reverse DNS (if desired) with local addresses, the stub + resolvers must look for DNS information from the local DNS servers, + not e.g. starting from the root servers, so that the local + information may be provided locally. Note that the experience of + private addresses in IPv4 has shown that the root servers get loaded + for requests for private address lookups in any case. This + requirement is discussed in [I-D.ietf-ipv6-unique-local-addr]. + +Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments + + DNS responses do not always fit in a single UDP packet. We'll + examine the cases which happen when this is due to too much data in + the Additional Section. + + + + + + +Durand, et al. Expires January 17, 2006 [Page 25] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +B.1 Description of Additional Data Scenarios + + There are two kinds of additional data: + + 1. "critical" additional data; this must be included in all + scenarios, with all the RRsets, and + + 2. "courtesy" additional data; this could be sent in full, with only + a few RRsets, or with no RRsets, and can be fetched separately as + well, but at the cost of additional queries. + + The responding server can algorithmically determine which type the + additional data is by checking whether it's at or below a zone cut. + + Only those additional data records (even if sometimes carelessly + termed "glue") are considered "critical" or real "glue" if and only + if they meet the abovementioned condition, as specified in Section + 4.2.1 of [RFC1034]. + + Remember that resource record sets (RRsets) are never "broken up", so + if a name has 4 A records and 5 AAAA records, you can either return + all 9, all 4 A records, all 5 AAAA records or nothing. In + particular, notice that for the "critical" additional data getting + all the RRsets can be critical. + + In particular, [RFC2181] specifies (in Section 9) that: + + a. if all the "critical" RRsets do not fit, the sender should set + the TC bit, and the recipient should discard the whole response + and retry using mechanism allowing larger responses such as TCP. + + b. "courtesy" additional data should not cause the setting of TC + bit, but instead all the non-fitting additional data RRsets + should be removed. + + An example of the "courtesy" additional data is A/AAAA records in + conjunction with MX records as shown in Section 4.4; an example of + the "critical" additional data is shown below (where getting both the + A and AAAA RRsets is critical w.r.t. to the NS RR): + + child.example.com. IN NS ns.child.example.com. + ns.child.example.com. IN A 192.0.2.1 + ns.child.example.com. IN AAAA 2001:db8::1 + + When there is too much "courtesy" additional data, at least the non- + fitting RRsets should be removed [RFC2181]; however, as the + additional data is not critical, even all of it could be safely + removed. + + + +Durand, et al. Expires January 17, 2006 [Page 26] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + When there is too much "critical" additional data, TC bit will have + to be set, and the recipient should ignore the response and retry + using TCP; if some data were to be left in the UDP response, the + issue is which data could be retained. + + Failing to discard the response with TC bit or omitting critical + information but not setting TC bit lead to an unrecoverable problem. + Omitting only some of the RRsets if all would not fit (but not + setting TC bit) leads to a performance problem. These are discussed + in the next two subsections. + +B.2 Which Additional Data to Keep, If Any? + + If the implementation decides to keep as much data (whether + "critical" or "courtesy") as possible in the UDP responses, it might + be tempting to use the transport of the DNS query as a hint in either + of these cases: return the AAAA records if the query was done over + IPv6, or return the A records if the query was done over IPv4. + However, this breaks the model of independence of DNS transport and + resource records, as noted in Section 1.2. + + With courtesy additional data, as long as enough RRsets will be + removed so that TC will not be set, it is allowed to send as many + complete RRsets as the implementations prefers. However, the + implementations are also free to omit all such RRsets, even if + complete. Omitting all the RRsets (when removing only some would + suffice) may create a performance penalty, whereby the client may + need to issue one or more additional queries to obtain necessary + and/or consistent information. + + With critical additional data, the alternatives are either returning + nothing (and absolutely requiring a retry with TCP) or returning + something (working also in the case if the recipient does not discard + the response and retry using TCP) in addition to setting the TC bit. + If the process for selecting "something" from the critical data would + otherwise be practically "flipping the coin" between A and AAAA + records, it could be argued that if one looked at the transport of + the query, it would have a larger possibility of being right than + just 50/50. In other words, if the returned critical additional data + would have to be selected somehow, using something more sophisticated + than a random process would seem justifiable. + + That is, leaving in some intelligently selected critical additional + data is a tradeoff between creating an optimization for those + resolvers which ignore the "should discard" recommendation, and + causing a protocol problem by propagating inconsistent information + about "critical" records in the caches. + + + + +Durand, et al. Expires January 17, 2006 [Page 27] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + Similarly, leaving in the complete courtesy additional data RRsets + instead of removing all the RRsets is a performance tradeoff as + described in the next section. + +B.3 Discussion of the Potential Problems + + As noted above, the temptation for omitting only some of the + additional data could be problematic. This is discussed more below. + + For courtesy additional data, this causes a potential performance + problem as this requires that the clients issue re-queries for the + potentially omitted RRsets. For critical additional data, this + causes a potential unrecoverable problem if the response is not + discarded and the query not re-tried with TCP, as the nameservers + might be reachable only through the omitted RRsets. + + If an implementation would look at the transport used for the query, + it is worth remembering that often the host using the records is + different from the node requesting them from the authoritative DNS + server (or even a caching resolver). So, whichever version the + requestor (e.g., a recursive server in the middle) uses makes no + difference to the ultimate user of the records, whose transport + capabilities might differ from those of the requestor. This might + result in e.g., inappropriately returning A records to an IPv6-only + node, going through a translation, or opening up another IP-level + session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). + Therefore, at least in many scenarios, it would be very useful if the + information returned would be consistent and complete -- or if that + is not feasible, return no misleading information but rather leave it + to the client to query again. + + The problem of too much additional data seems to be an operational + one: the zone administrator entering too many records which will be + returned either truncated (or missing some RRsets, depending on + implementations) to the users. A protocol fix for this is using + EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes, + pushing up the relevant threshold. Further, DNS server + implementations should rather omit courtesy additional data + completely rather than including only some RRsets [RFC2181]. An + operational fix for this is having the DNS server implementations + return a warning when the administrators create zones which would + result in too much additional data being returned. Further, DNS + server implementations should warn of or disallow such zone + configurations which are recursive or otherwise difficult to manage + by the protocol. + + Additionally, to avoid the case where an application would not get an + address at all due to some of courtesy additional data being omitted, + + + +Durand, et al. Expires January 17, 2006 [Page 28] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + + the resolvers should be able to query the specific records of the + desired protocol, not just rely on getting all the required RRsets in + the additional section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires January 17, 2006 [Page 29] + +Internet-Draft Considerations with IPv6 DNS July 2005 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2005). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Durand, et al. Expires January 17, 2006 [Page 30] + + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt new file mode 100644 index 0000000..b2e2341 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt @@ -0,0 +1,300 @@ +Internet Engineering Task Force A.Durand +INTERNET-DRAFT SUN Microsystems,inc. +November, 24, 2003 J. Ihren +Expires May 25, 2004 Autonomica + + + DNS IPv6 transport operational guidelines + <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt> + + + +Status of this Memo + + This memo provides information to the Internet community. It does not + specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 + + 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 + + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + +Abstract + + This memo provides guidelines and Best Current Practice to operate + DNS in a world where queries and responses are carried in a mixed + environment of IPv4 and IPv6 networks. + + +Acknowledgment + + This document is the result of many conversations that happened in + the DNS community at IETF and elsewhere since 2001. During that + period of time, a number of Internet drafts have been published to + clarify various aspects of the issues at stake. This document focuses + on the conclusion of those discussions. + + The authors would like to acknowledge the role of Pekka Savola in his + thorough review of the document. + + +1. Terminology + + The phrase "IPv4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS data is + served. Likewise, "IPv6 name server" indicates a name server + available over IPv6 transport. The phrase "dual-stack DNS server" + indicates a DNS server that is actually configured to run both + protocols, IPv4 and IPv6, and not merely a server running on a system + capable of running both but actually configured to run only one. + + 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 [2119]. + + +2. Introduction to the Problem of Name Space Fragmentation: + following the referral chain + + The caching resolver that tries to look up a name starts out at the + root, and follows referrals until it is referred to a nameserver that + is authoritative for the name. If somewhere down the chain of + referrals it is referred to a nameserver that is only accessible over + an unavailable type of transport, a traditional nameserver is unable + to finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen. The complete DNS + hierarchy then starts to fragment into a graph where authoritative + nameservers for certain nodes are only accessible over a certain + transport. What is feared is that a node using only a particular + version of IP, querying information about another node using the same + version of IP can not do it because, somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + through a "translator", i.e. they have to use a second name server on + a so-called "dual stack" host as a "forwarder" since they cannot + access the DNS data directly. + + With all DNS data only available over IPv6 transport everything would + be equally simple, with the exception of old legacy IPv4 name servers + having to switch to a forwarding configuration. + + However, the second situation will not arise in a foreseeable time. + Instead, it is expected that the transition will be from IPv4 only to + a mixture of IPv4 and IPv6, with DNS data of theoretically three + categories depending on whether it is available only over IPv4 + transport, only over IPv6 or both. + + Having DNS data available on both transports is the best situation. + The major question is how to ensure that it as quickly as possible + becomes the norm. However, while it is obvious that some DNS data + will only be available over v4 transport for a long time it is also + obvious that it is important to avoid fragmenting the name space + available to IPv4 only hosts. I.e. during transition it is not + acceptable to break the name space that we presently have available + for IPv4-only hosts. + + +3. Policy Based Avoidance of Name Space Fragmentation + + Today there are only a few DNS "zones" on the public Internet that + are available over IPv6 transport, and most of them can be regarded + as "experimental". However, as soon as the root and top level domains + are available over IPv6 transport, it is reasonable to expect that it + will become more common to have zones served by IPv6 servers. + + Having those zones served only by IPv6-only name server would not be + a good development, since this will fragment the previously + unfragmented IPv4 name space and there are strong reasons to find a + mechanism to avoid it. + + The RECOMMENDED approach to maintain name space continuity is to use + administrative policies, as described in the next section. + + +4. DNS IPv6 Transport RECOMMENDED Guidelines + + In order to preserve name space continuity, the following administrative + policies are RECOMMENDED: + - every recursive DNS server SHOULD be either IPv4-only or dual + stack, + - every single DNS zone SHOULD be served by at least one IPv4 + reachable DNS server. + + This rules out IPv6-only DNS servers performing full recursion and + DNS zones served only by IPv6-only DNS servers. However, one could + very well design a configuration where a chain of IPv6 only DNS + servers forward queries to a set of dual stack DNS servers actually + performing those recursive queries. This approach could be revisited + if/when translation techniques between IPv4 and IPv6 were to be + widely deployed. + + In order to help enforcing the second point, the optional operational + zone validation processes SHOULD ensure that there is at least one + IPv4 address record available for the name servers of any child + delegations within the zone. + + +5. Security Considerations + + Being a critical piece of the Internet infrastructure, the DNS is a + potential value target and thus should be protected. Great care + should be taken not to weaken the security of DNS while introducing + IPv6 operation. + + Keeping the DNS name space from fragmenting is a critical thing for + the availability and the operation of the Internet; this memo + addresses this issue by clear and simple operational guidelines. + + The RECOMMENDED guidelines are compatible with the operation of + DNSSEC and do not introduce any new security issues. + + +6. Author Addresses + + Alain Durand + SUN Microsystems, Inc + 17 Network circle UMPK17-202 + Menlo Park, CA, 94025 + USA + Mail: Alain.Durand@sun.com + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm, Sweden + Mail: johani@autonomica.se + + +7. Normative References + + [2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +8. Full Copyright Statement + + "Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt new file mode 100644 index 0000000..6bece56 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt @@ -0,0 +1,389 @@ + +DNSOP G. Guette +Internet-Draft IRISA / INRIA +Expires: July 19, 2005 O. Courtay + Thomson R&D + January 18, 2005 + + Requirements for Automated Key Rollover in DNSSEC + draft-ietf-dnsop-key-rollover-requirements-02.txt + +Status of this Memo + + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 19, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). All Rights Reserved. + +Abstract + + This document describes problems that appear during an automated + rollover and gives the requirements for the design of communication + between parent zone and child zone during an automated rollover + process. This document is essentially about in-band key rollover. + + + + +Guette & Courtay Expires July 19, 2005 [Page 1] +Internet-Draft Automated Rollover Requirements January 2005 + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 + 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Messages authentication and information exchanged . . . . . . 5 + 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 + 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 + A. Documents details and changes . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 2] +Internet-Draft Automated Rollover Requirements January 2005 + +1. Introduction + + The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key + cryptography and digital signatures. It stores the public part of + keys in DNSKEY Resource Records (RRs). Because old keys and + frequently used keys are vulnerable, they must be renewed + periodically. In DNSSEC, this is the case for Zone Signing Keys + (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key + exchanges between parents and children is necessary for large zones + because there are too many changes to handle. + + Let us consider for example a zone with 100000 secure delegations. + If the child zones change their keys once a year on average, that + implies 300 changes per day for the parent zone. This amount of + changes is hard to manage manually. + + Automated rollover is optional and resulting from an agreement + between the administrator of the parent zone and the administrator of + the child zone. Of course, key rollover can also be done manually by + administrators. + + This document describes the requirements for a protocol to perform + the automated key rollover process and focusses on interaction + between parent and child zone. + +2. The Key Rollover Process + + Key rollover consists of renewing the DNSSEC keys used to sign + resource records in a given DNS zone file. There are two types of + rollover, ZSK rollovers and KSK rollovers. + + During a ZSK rollover, all changes are local to the zone that renews + its key: there is no need to contact other zones administrators to + propagate the performed changes because a ZSK has no associated DS + record in the parent zone. + + During a KSK rollover, new DS RR(s) must be created and stored in the + parent zone. In consequence, data must be exchanged between child + and parent zones. + + The key rollover is built from two parts of different nature: + o An algorithm that generates new keys and signs the zone file. It + can be local to the zone, + o the interaction between parent and child zones. + + One example of manual key rollover [3] is: + o The child zone creates a new KSK, + + +Guette & Courtay Expires July 19, 2005 [Page 3] +Internet-Draft Automated Rollover Requirements January 2005 + + o the child zone waits for the creation of the DS RR in its parent + zone, + o the child zone deletes the old key, + o the parent zone deletes the old DS RR. + + This document concentrates on defining interactions between entities + present in key rollover process. + +3. Basic Requirements + + This section provides the requirements for automated key rollover in + case of normal use. Exceptional case like emergency rollover is + specifically described later in this document. + + The main condition during a key rollover is that the chain of trust + must be preserved to every validating DNS client. No matter if this + client retrieves some of the RRs from recursive caching name server + or from the authoritative servers for the zone involved in the + rollover. + + Automated key rollover solution may be interrupted by a manual + intervention. This manual intervention should not compromise the + security state of the chain of trust. If the chain is safe before + the manual intervention, the chain of trust must remain safe during + and after the manual intervention + + Two entities act during a KSK rollover: the child zone and its parent + zone. These zones are generally managed by different administrators. + These administrators should agree on some parameters like + availability of automated rollover, the maximum delay between + notification of changes in the child zone and the resigning of the + parent zone. The child zone needs to know this delay to schedule its + changes and/or to verify that the changes had been taken into account + in the parent zone. Hence, the child zone can also avoid some + critical cases where all child key are changed prior to the DS RR + creation. + + By keeping some resource records during a given time, the recursive + cache servers can act on the automated rollover. The existence of + recursive cache servers must be taken into account by automated + rollover solution. + + Indeed, during an automated key rollover a name server could have to + retrieve some DNSSEC data. An automated key rollover solution must + ensure that these data are not old DNSSEC material retrieved from a + recursive name server. + + + +Guette & Courtay Expires July 19, 2005 [Page 4] +Internet-Draft Automated Rollover Requirements January 2005 + +4. Messages authentication and information exchanged + + This section addresses in-band rollover, security of out-of-band + mechanisms is out of scope of this document. + + The security provided by DNSSEC must not be compromised by the key + rollover, thus every exchanged message must be authenticated to avoid + fake rollover messages from malicious parties. + + Once the changes related to a KSK are made in a child zone, there are + two ways for the parent zone to take this changes into account: + o the child zone notify directly or not directly its parent zone in + order to create the new DS RR and store this DS RR in parent zone + file, + o or the parent zone poll the child zone. + + In both cases, the parent zone must receive all the child keys that + need the creation of associated DS RRs in the parent zone. + + Because errors could occur during the transmission of keys between + child and parent, the key exchange protocol must be fault tolerant. + Should an error occured during the automated key rollover, an + automated key rollover solution must be able to keep the zone files + in a consistent state. + +5. Emergency Rollover + + Emergency key rollover is a special case of rollover decided by the + zone administrator generally for security reasons. In consequence, + emergency key rollover can break some of the requirement described + above. + + A zone key might be compromised and an attacker can use the + compromised key to create and sign fake records. To avoid this, the + zone administrator may change the compromised key or all its keys as + soon as possible, without waiting for the creation of new DS RRs in + its parent zone. + + Fast changes may break the chain of trust. The part of DNS tree + having this zone as apex can become unverifiable, but the break of + the chain of trust is necessary if the administrator wants to prevent + the compromised key from being used (to spoof DNS data). + + Parent and child zones sharing an automated rollover mechanism, + should have an out-of-band way to re-establish a consistent state at + the delegation point (DS and DNSKEY RRs). This allows to avoid that + a malicious party uses the compromised key to roll the zone keys. + + +Guette & Courtay Expires July 19, 2005 [Page 5] +Internet-Draft Automated Rollover Requirements January 2005 + +6. Security consideration + + The automated key rollover process in DNSSEC allows automated renewal + of any kind of DNS key (ZSK or KSK). It is essential that parent + side and child side can do mutual authentication. Moreover, + integrity of the material exchanged between the parent and child zone + must be provided to ensure the right DS are created. + + As in any application using public key cryptography, in DNSSEC a key + may be compromised. What to do in such a case can be describe in the + zone local policy and can violate some requirements described in this + draft. The emergency rollover can break the chain of trust in order + to protect the zone against the use of the compromised key. + +7. Acknowledgments + + The authors want to thank members of IDsA project for their + contribution to this document. + +8 Normative References + + [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", + RFC 3658, December 2003. + + [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY + (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", + RFC 3757, May 2004. + + [3] Kolkman, O., "DNSSEC Operational Practices", + draft-ietf-dnsop-dnssec-operational-practice-01 (work in + progress), May 2004. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-11 (work in progress), October + 2004. + + [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-13 (work in progress), October + 2004. + + [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October + + +Guette & Courtay Expires July 19, 2005 [Page 6] +Internet-Draft Automated Rollover Requirements January 2005 + + 2004. + +Authors' Addresses + + Gilles Guette + IRISA / INRIA + Campus de Beaulieu + 35042 Rennes CEDEX + FR + + EMail: gilles.guette@irisa.fr + URI: http://www.irisa.fr + + Olivier Courtay + Thomson R&D + 1, avenue Belle Fontaine + 35510 Cesson S?vign? CEDEX + FR + + EMail: olivier.courtay@thomson.net + +Appendix A. Documents details and changes + + This section is to be removed by the RFC editor if and when the + document is published. + + Section about NS RR rollover has been removed + + Remarks from Samuel Weiler and Rip Loomis added + + Clarification about in-band rollover and in emergency section + + Section 3, details about recursive cache servers added + + + + + + + + +Guette & Courtay Expires July 19, 2005 [Page 7] +Internet-Draft Automated Rollover Requirements January 2005 + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described + in this document or the extent to which any license under such + rights might or might not be available; neither does it represent + that it has made any effort to identify any such rights. + Information on the IETF's procedures with respect to rights in + IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr.org. + + + Full 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. + + 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. + + Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + +Guette & Courtay Expires July 19, 2005 [Page 8] diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-01.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-01.txt new file mode 100644 index 0000000..8298bb2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-01.txt @@ -0,0 +1,1008 @@ + + + +DNSOP W. Hardaker +Internet-Draft Sparta, Inc. +Intended status: Informational September 3, 2008 +Expires: March 7, 2009 + + + Requirements for Management of Name Servers for the DNS + draft-ietf-dnsop-name-server-management-reqs-01.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 March 7, 2009. + +Abstract + + Management of name servers for the Domain Name Service (DNS) has + traditionally been done using vendor-specific monitoring, + configuration and control methods. Although some service monitoring + platforms can test the functionality of the DNS itself there is not a + interoperable way to manage (monitor, control and configure) the + internal aspects of a name server itself. + + This document discusses the requirements of a management system for + DNS name servers. A management solution that is designed to manage + the DNS can use this document as a shopping list of needed features. + + + + + +Hardaker Expires March 7, 2009 [Page 1] + +Internet-Draft Name Server Management Requirements September 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 + 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 + 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 + 2. Management Architecture Requirements . . . . . . . . . . . . . 5 + 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 + 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 + 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 + 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 + 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 + 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6 + 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7 + 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 + 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 + 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 + 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 + 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 + 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 + 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 + 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 + 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 + 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 + 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9 + 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 + 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 + 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 + 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 + 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 + 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 + 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 + 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 + 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 + 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 + 5.1.3. Namespace Collision Protection . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 + Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 + A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 + A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 + + + +Hardaker Expires March 7, 2009 [Page 2] + +Internet-Draft Name Server Management Requirements September 2008 + + + A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . . . . 18 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hardaker Expires March 7, 2009 [Page 3] + +Internet-Draft Name Server Management Requirements September 2008 + + +1. Introduction + + Management of name servers for the Domain Name Service (DNS) + [RFC1034] [RFC1035] has traditionally been done using vendor-specific + monitoring, configuration and control methods. Although some service + monitoring platforms can test the functionality of the DNS itself + there is not a interoperable way to manage (monitor, control and + configure) the internal aspects of a name server itself. + + Previous standardization work within the IETF resulted in the + creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed + to achieve significant implementation and deployment. The perceived + reasons behind the failure for the two MIB modules are further + documented in [RFC3197]. + + This document discusses the requirements of a management system for + DNS name servers. A management solution that is designed to manage + the DNS can use this document as a shopping list of needed features. + + Specifically out of scope for this document are requirements + associated with management of stub resolvers. It is not the intent + of this document to document stub resolver requirements, although + some of the requirements listed are applicable to stub resolvers as + well. + + Also out of scope for this document is management of the host or + other components of the host upon which the name server software is + running. This document only discusses requirements for managing the + name server component of a system. + + The task of creating a management system for managing DNS servers is + not expected to be a small one. It is likely that components of the + solution will need to be designed in parts over time and these + requirements take this into consideration. In particular, + Section 5.1 discusses the need for future extensibility of the base + management solution. This document is intended to be a road-map + towards a desired outcome and is not intended to define an "all-or- + nothing" system. Successful interoperable management of name servers + even in part is expected to be beneficial to network operators + compared to the entirely custom solutions that are used at the time + of this writing. + +1.1. Requirements notation + + 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]. + + + + +Hardaker Expires March 7, 2009 [Page 4] + +Internet-Draft Name Server Management Requirements September 2008 + + +1.1.1. Terminology + + This document is consistent with the terminology defined in Section 2 + of [RFC4033]. Additional terminology needed for this document is + described below: + + Name Server: When we are discussing servers that don't fall into a + more specific type of server category defined in other documents, + this document will refer to them generically as "name servers". + In particular "name servers" can be considered to be any valid + combination of authoritative, recursive, validating, or security- + aware. The more specific name server labels will be used when + this document refers only to a specific type of server. However, + the term "name server", in this document, will not include stub + resolvers. + +1.1.2. Document Layout and Requirements + + The document is written so that each numbered section will contain + only a single requirement if it contains one at all. Each + requirement will contain needed wording from the terminology + described in Section 1.1. Subsections, however, might exist with + additional related requirements. The document is laid out in this + way so that a specific requirement can be uniquely referred to using + the section number itself and the document version from which it + came. + + +2. Management Architecture Requirements + + This section discusses requirements that reflect the needs of the + expected deployment environments. + +2.1. Expected Deployment Scenarios + + DNS zones vary greatly in the type of content published within them. + Name Servers, too, are deployed with a wide variety of configurations + to support the diversity of the deployed content. It is important + that a management solution trying to meet the criteria specified in + this document consider supporting the largest number of potential + deployment cases as possible. Further deployment scenarios that are + not used as direct examples of specific requirements are listed in + Appendix A. + +2.1.1. Zone Size Constraints + + The management solution MUST support both name servers that are + serving a small number of potentially very large zones (e.g. Top + + + +Hardaker Expires March 7, 2009 [Page 5] + +Internet-Draft Name Server Management Requirements September 2008 + + + Level Domains (TLDs)) as well as name servers that are serving a very + large number of small zones. These scenarios are both commonly seen + deployments. + +2.1.2. Name Server Discovery + + Large enterprise network deployments may contain multiple name + servers operating within the boundaries of the enterprise network. + These name servers may each be serving multiple zones both in and out + of the parent enterprise's zone. Finding and managing large + quantities of name servers would be a useful feature of the resulting + management solution. The management solution MAY support the ability + to discover previously unknown instances of name servers operating + within a deployed network. + +2.1.3. Configuration Data Volatility + + Configuration data is defined as data that relates only to the + configuration of a server and the zones it serves. It specifically + does not include data from the zone contents that is served through + DNS itself. The solution MUST support servers that remain fairly + statically configured over time as well as servers that have numerous + zones being added and removed within an hour. Both of these + scenarios are also commonly seen deployments. + +2.1.4. Protocol Selection + + There are many requirements in this document for many different types + of management operations (see Section 3 for further details). It is + possible that no one protocol will ideally fill all the needs of the + requirements listed in this document and thus multiple protocols + might be needed to produce a completely functional management system. + Multiple protocols might be used to create the complete management + solution, but the number of protocols used SHOULD be reduced to a + reasonable minimum number. + +2.1.5. Common Data Model + + Defining a standardized protocol (or set of protocols) to use for + managing name servers would be a step forward in achieving an + interoperable management solution. However, just defining a protocol + to use by itself would not achieve the complete end goal of a + complete interoperable management solution. Devices also need to + represent their internal management interface using a common + management data model. The solution MUST create a common data model + that management stations can make use of when sending or collecting + data from a managed device so it can successfully manage equipment + from vendors as if they were generic DNS servers. This common data + + + +Hardaker Expires March 7, 2009 [Page 6] + +Internet-Draft Name Server Management Requirements September 2008 + + + model is needed for of the operations discussion in Section 3. Note + that this does not preclude the fact that name server vendors might + provide additional management infrastructure beyond a base management + specification, as discussed further in Section 5.1. + +2.1.6. Operational Impact + + It is impossible to add new features to an existing server (such as + the inclusion of a management infrastructure) and not impact the + existing service and/or server in some fashion. At a minimum, for + example, more memory, disk and/or CPU resources will be required to + implement a new management system. However, the impact to the + existing DNS service MUST be minimized since the DNS service itself + is still the primary service to be offered by the modified name + server. + +2.2. Name Server Types + + There are multiple ways in which name servers can be deployed. Name + servers can take on any of the following roles: + + o Master Servers + + o Slave Servers + + o Recursive Servers + + The management solution SHOULD support all of these types of name + servers as they are all equally important. Note that "Recursive + Servers" can be further broken down by the security sub-roles they + might implement, as defined in section 2 of [RFC4033]. These sub- + roles are also important to support within any management solution. + + The requirements in this document explicitly exclude dealing with + management of stub resolvers. Management of stub resolvers is + considered specifically out of scope of this document. + + +3. Management Operation Types + + Management operations can traditionally be broken into four + categories: + + o Control + + o Configuration + + + + + +Hardaker Expires March 7, 2009 [Page 7] + +Internet-Draft Name Server Management Requirements September 2008 + + + o Health and Monitoring + + o Alarms and Events + + This section discusses requirements for each of these four management + types in detail. + +3.1. Control Requirements + + The management solution MUST be capable of performing basic service + control operations. + +3.1.1. Needed Control Operations + + These operations SHOULD include, at a minimum, the following + operations: + + o Starting the name server + + o Reloading the service configuration + + o Reloading zone data + + o Restarting the name server + + o Stopping the name server + + Note that no restriction is placed on how the management system + implements these operations. In particular, at least "starting the + name server" will require a minimal management system component to + exist independently of the name server itself. + +3.1.2. Asynchronous Status Notifications + + Some control operations might take a long time to complete. As an + example, some name servers take a long time to perform reloads of + large zones. Because of these timing issues, the management solution + SHOULD take this into consideration and offer a mechanism to ease the + burden associated with awaiting the status of a long-running command. + This could, for example, result in the use of asynchronous + notifications for returning the status of a long-running task or it + might require the management station to poll for the status of a + given task using monitoring commands. These and other potential + solutions need to be evaluated carefully to select one that balances + the result delivery needs with the perceived implementation costs. + + Also, see the related discussion in Section 3.4 on notification + messages for supporting delivery of alarm and event messages. + + + +Hardaker Expires March 7, 2009 [Page 8] + +Internet-Draft Name Server Management Requirements September 2008 + + +3.2. Configuration Requirements + + Many features of name servers need to be configured before the server + can be considered functional. The management solution MUST be able + to provide name servers with configuration data. The most important + data to be configured, for example, is the served zone data itself. + +3.2.1. Served Zone Modification + + The ability to add, modify and delete zones being served by name + servers is needed. Although there are already solutions for zone + content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], + AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that + might be used as part of the final management solution, the + management system SHOULD still be able to natively create a new zone + (with enough minimal data to allow the other mechanisms to function + as well) as well as delete a zone. This might be, for example, a + management operation that at least allows for the creation of the + initial SOA record for a new zone as that's the minimum amount of + zone data needed for the other operations to function. + +3.2.2. Trust Anchor Management + + The solution SHOULD support the ability to add, modify and delete + trust anchors that are used by DNS Security (DNSSEC) [RFC4033] + [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust + anchors might be configured using the data from the DNSKEY Resource + Records (RRs) themselves or by using Delegation Signer (DS) + fingerprints. + +3.2.3. Security Expectations + + DNSSEC Validating resolvers need to make policy decisions about the + requests being processed. For example, they need to be configured + with a list of zones expected to be secured by DNSSEC. The + management solution SHOULD be able to add, modify and delete + attributes of DNSSEC security policies. + +3.2.4. TSIG Key Management + + TSIG [RFC2845] allows transaction level authentication of DNS + traffic. The management solution SHOULD be able to add, modify and + delete TSIG keys known to the name server. + +3.2.5. DNS Protocol Authorization Management + + The management solution SHOULD have the ability to add, modify and + delete authorization settings for the DNS protocols itself. Do not + + + +Hardaker Expires March 7, 2009 [Page 9] + +Internet-Draft Name Server Management Requirements September 2008 + + + confuse this with the ability to manage the authorization associated + with the management protocol itself, which is discussed later in + Section 4.4. There are a number of authorization settings that are + used by a name server. Example authorization settings that the + solution might need to cover are: + + o Access to operations on zone data (e.g. DDNS) + + o Access to certain zone data from certain sources (e.g. from + particular network subnets) + + o Access to specific DNS protocol services (e.g. recursive service) + + Note: the above list is expected to be used as a collection of + examples and is not a complete list of needed authorization + protections. + +3.3. Monitoring Requirements + + Monitoring is the process of collecting aspects of the internal state + of a name server at a given moment in time. The solution MUST be + able to monitor the health of a name server to determine its + operational status, load and other internal attributes. Example + management tasks that the solution might need to cover are: + + o Number of requests sent, responses sent, average response latency + and other performance counters + + o Server status (e.g. "serving data", "starting up", "shutting + down", ...) + + o Access control violations + + o List of zones being served + + o Detailed statistics about clients interacting with the name server + (e.g. top 10 clients requesting data). + + Note: the above list is expected to be used as a collection of + examples and is not a complete list of needed monitoring operations. + In particular, some monitoring statistics are expected to be + computationally or resource expensive and are considered to be "nice + to haves" as opposed to "necessary to have". + +3.4. Alarm and Event Requirements + + Events occurring at the name server that trigger alarm notifications + can quickly inform a management station about critical issues. A + + + +Hardaker Expires March 7, 2009 [Page 10] + +Internet-Draft Name Server Management Requirements September 2008 + + + management solution SHOULD include support for delivery of alarm + conditions. + + Example alarm conditions might include: + + o The server's status is changing. (e.g it is starting up, reloading + configuration, restarting or shutting down) + + o A needed resource (e.g. memory or disk space) is exhausted or + nearing exhaustion + + o An authorization violation was detected + + o The server has not received any data traffic (e.g. DNS requests + or NOTIFYs) recently (AKA the "lonely warning"). This condition + might indicate a problem with its deployment. + + +4. Security Requirements + + The management solution will need to be appropriately secured against + attacks on the management infrastructure. + +4.1. Authentication + + The solution MUST support mutual authentication. The management + client needs to be assured that the management operations are being + transferred to and from the correct name server. The managed name + server needs to authenticate the system that is accessing the + management infrastructure within itself. + +4.2. Integrity Protection + + Management operations MUST be protected from modification while in + transit from the management client to the server. + +4.3. Confidentiality + + The management solution MUST support message confidentiality. The + potential transfer of sensitive configuration is expected (such as + TSIG keys or security policies). The solution does not, however, + necessarily need to provide confidentiality to data that would + normally be carried without confidentiality by the DNS system itself. + +4.4. Authorization + + The solution SHOULD be capable of providing a fine-grained + authorization model for any management protocols it introduces to the + + + +Hardaker Expires March 7, 2009 [Page 11] + +Internet-Draft Name Server Management Requirements September 2008 + + + completed system. This authorization differs from the authorization + previously discussed in Section 3.2.5 in that this requirement is + concerned solely with authorization of the management system itself. + + There are a number of authorization settings that might be used by a + managed system to determine whether the managing entity has + authorization to perform the given management task. Example + authorization settings that the solution might need to cover are: + + o Access to the configuration that specifies which zones are to be + served + + o Access to the management system infrastructure + + o Access to other control operations + + o Access to other configuration operations + + o Access to monitoring operations + + Note: the above list is expected to be used as a collection of + examples and is not a complete list of needed authorization + protections. + +4.5. Solution Impacts on Security + + The solution MUST minimize the security risks introduced to the + complete name server system. It is impossible to add new + infrastructure to a server and not impact the security in some + fashion as the introduction of a management protocol alone will + provide a new avenue for potential attack. Although the added + management benefits will be worth the increased risks, the solution + still needs to minimize this impact as much as possible. + + +5. Other Requirements + +5.1. Extensibility + + The management solution is expected to change and expand over time as + lessons are learned and new DNS features are deployed. Thus, the + solution MUST be flexible and be able to accommodate new future + management operations. The solution might, for example, make use of + protocol versioning or capability description exchanges to ensure + that management stations and name servers that weren't written to the + same specification version can still interoperate to the best of + their combined ability. + + + + +Hardaker Expires March 7, 2009 [Page 12] + +Internet-Draft Name Server Management Requirements September 2008 + + +5.1.1. Vendor Extensions + + It MUST be possible for vendors to extend the standardized management + model with vendor-specific extensions to support additional features + offered by their products. + +5.1.2. Extension Identification + + It MUST be possible for a management station to understand which + parts of returned data are specific to a given vendor or other + standardized extension. The data returned needs to be appropriately + marked through the use of name spaces or similar mechanisms to ensure + that the base management model data can be logically separated from + extension data without needing to understand the extension data + itself. + +5.1.3. Namespace Collision Protection + + It MUST be possible to protect against multiple extensions + conflicting with each other. The use of name-space protection + mechanisms for communicated management variables is common practice + to protect against problems. Name-space identification techniques + also frequently solve the "Extension Identification" requirement + discussed in Section 5.1.2 as well. + + +6. Security Considerations + + Any management protocol that meets the criteria discussed in this + document needs to support the criteria discussed in Section 4 in + order to protect the management infrastructure itself. The DNS is a + core Internet service and management traffic that protects it could + be the target of attacks designed to subvert that service. Because + the management infrastructure will be adding additional interfaces to + that service, it is critical that the management infrastructure + support adequate protections against network attacks. + + +7. IANA Considerations + + No action is required from IANA for this document. + + +8. Document History + + A requirement gathering discussion was held at the December 2007 IETF + meeting in Vancouver, BC, Canada and a follow up meeting was held at + the March 2008 IETF meeting in Philadelphia. This document is a + + + +Hardaker Expires March 7, 2009 [Page 13] + +Internet-Draft Name Server Management Requirements September 2008 + + + compilation of the results of those discussions as well as + discussions on the DCOMA mailing list. + + +9. Acknowledgments + + This draft is the result of discussions within the DCOMA design team + chaired by Jaap Akkerhuis. This team consisted of a large number of + people all of whom provided valuable insight and input into the + discussions surrounding name server management. The text of this + document was written from notes taken during meetings as well as from + contributions sent to the DCOMA mailing list. This work documents + the consensus of the DCOMA design team. + + In particular, the following team members contributed significantly + to the text in the document: + + Stephane Bortzmeyer + + Stephen Morris + + Phil Regnauld + + Further editing contributions and wording suggestions were made by: + Alfred Hines. + + +10. References + +10.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", + RFC 2136, April 1997. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + + + +Hardaker Expires March 7, 2009 [Page 14] + +Internet-Draft Name Server Management Requirements September 2008 + + + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [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. + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) + Trust Anchors", RFC 5011, September 2007. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + +10.2. Informative References + + [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", + RFC 1611, May 1994. + + [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", + RFC 1612, May 1994. + + [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection + and Operation of Secondary DNS Servers", BCP 16, RFC 2182, + July 1997. + + [RFC3197] Austein, R., "Applicability Statement for DNS MIB + Extensions", RFC 3197, November 2001. + + +Appendix A. Deployment Scenarios + + This appendix documents some additional deployment scenarios that + have been traditionally difficult to manage. They are provided as + + + +Hardaker Expires March 7, 2009 [Page 15] + +Internet-Draft Name Server Management Requirements September 2008 + + + guidance to protocol developers as data points of real-world name + server management problems. + +A.1. Non-Standard Zones + + If an organization uses non-standard zones (for example a purely- + local TLD), synchronizing all the nameservers for these zones is + usually a time-consuming task. It is made worse when two + organizations with conflicting zones merge. This situation is not a + recommended deployment scenario (and is even heavily discouraged) but + it is, unfortunately, seen in the wild. + + It is typically implemented using "forwarding" zones. But there is + no way to ensure automatically that all the resolvers have the same + set of zones to forward at any given time. New zones might be added + to a local forwarding recursive server, for example, without + modifying the rest of the deployed forwarding servers. It is hoped + that a management solution which could handle the configuration of + zone forwarding would finally allow management of servers deployed in + this fashion. + +A.2. Redundancy Sharing + + For reliability reasons it is recommended that zone operators follow + the guidelines documented in [RFC2182] which recommends that multiple + name servers be configured for each zone and that the name servers + are separated both physically and via connectivity routes. A common + solution is to establish DNS-serving partnerships: "I'll host your + zones and you'll host mine". Both entities benefit from increased + DNS reliability via the wider service distribution. This frequently + occurs between cooperating but otherwise unrelated entities (such as + between two distinct companies) as well as between affiliated + organizations (such as between branch offices within a single + company). + + The configuration of these relationships are currently required to be + manually configured and maintained. Changes to the list of zones + that are cross-hosted are manually negotiated between the cooperating + network administrators and configured by hand. A management protocol + with the ability to provide selective authorization, as discussed in + Section 4.4, would solve many of the management difficulties between + cooperating organizations. + +A.3. DNSSEC Management + + There are many different DNSSEC deployment strategies that may be + used for mission-critical zones. The following list describes some + example deployment scenarios that might warrant different management + + + +Hardaker Expires March 7, 2009 [Page 16] + +Internet-Draft Name Server Management Requirements September 2008 + + + strategies. + + All contents and DNSSEC keying information controlled and operated + by a single organization + + Zone contents controlled and operated by one organization, all + DNSSEC keying information controlled and operated by a second + organization. + + Zone contents controlled and operated by one organization, zone + signing keys (ZSKs) controlled and operated by a second + organization, and key signing keys (KSKs) controlled and operated + by a third organization. + + Although this list is not exhaustive in the potential ways that zone + data can be divided up, it should be sufficient to illustrate the + potential ways in which zone data can be controlled by multiple + entities. + + The end result of all of these strategies, however, will be the same: + a live zone containing DNSSEC related resource records. Many of the + above strategies are merely different ways of preparing a zone for + serving. A management solution that includes support for managing + DNSSEC zone data may wish to take into account these potential + management scenarios. + + +Author's Address + + Wes Hardaker + Sparta, Inc. + P.O. Box 382 + Davis, CA 95617 + US + + Phone: +1 530 792 1913 + Email: ietf@hardakers.net + + + + + + + + + + + + + + +Hardaker Expires March 7, 2009 [Page 17] + +Internet-Draft Name Server Management Requirements September 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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. + + + + + + + + + + + +Hardaker Expires March 7, 2009 [Page 18] + diff --git a/doc/draft/draft-ietf-dnsop-respsize-06.txt b/doc/draft/draft-ietf-dnsop-respsize-06.txt new file mode 100644 index 0000000..b041925 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-respsize-06.txt @@ -0,0 +1,640 @@ + + + + + + + DNSOP Working Group Paul Vixie, ISC + INTERNET-DRAFT Akira Kato, WIDE + <draft-ietf-dnsop-respsize-06.txt> August 2006 + + DNS Referral Response Size Issues + + Status of this Memo + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Copyright Notice + + Copyright (C) The Internet Society (2006). All Rights Reserved. + + + + + Abstract + + With a mandated default minimum maximum message size of 512 octets, + the DNS protocol presents some special problems for zones wishing to + expose a moderate or high number of authority servers (NS RRs). This + document explains the operational issues caused by, or related to + this response size limit, and suggests ways to optimize the use of + this limited space. Guidance is offered to DNS server implementors + and to DNS zone operators. + + + + + Expires January 2007 [Page 1] + + INTERNET-DRAFT August 2006 RESPSIZE + + + 1 - Introduction and Overview + + 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 + octets. Even though this limitation was due to the required minimum IP + reassembly limit for IPv4, it became a hard DNS protocol limit and is + not implicitly relaxed by changes in transport, for example to IPv6. + + 1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits + larger responses by mutual agreement of the requester and responder. + The 512 octet message size limit will remain in practical effect until + there is widespread deployment of EDNS0 in DNS resolvers on the + Internet. + + 1.3. Since DNS responses include a copy of the request, the space + available for response data is somewhat less than the full 512 octets. + Negative responses are quite small, but for positive and delegation + responses, every octet must be carefully and sparingly allocated. This + document specifically addresses delegation response sizes. + + 2 - Delegation Details + + 2.1. RELEVANT PROTOCOL ELEMENTS + + 2.1.1. A delegation response will include the following elements: + + Header Section: fixed length (12 octets) + Question Section: original query (name, class, type) + Answer Section: empty, or a CNAME/DNAME chain + Authority Section: NS RRset (nameserver names) + Additional Section: A and AAAA RRsets (nameserver addresses) + + 2.1.2. If the total response size exceeds 512 octets, and if the data + that does not fit was "required", then the TC bit will be set + (indicating truncation). This will usually cause the requester to retry + using TCP, depending on what information was desired and what + information was omitted. For example, truncation in the authority + section is of no interest to a stub resolver who only plans to consume + the answer section. If a retry using TCP is needed, the total cost of + the transaction is much higher. See [RFC1123 6.1.3.2] for details on + the requirement that UDP be attempted before falling back to TCP. + + 2.1.3. RRsets are never sent partially unless TC bit set to indicate + truncation. When TC bit is set, the final apparent RRset in the final + non-empty section must be considered "possibly damaged" (see [RFC1035 + 6.2], [RFC2181 9]). + + + + Expires January 2007 [Page 2] + + INTERNET-DRAFT August 2006 RESPSIZE + + + 2.1.4. With or without truncation, the glue present in the additional + data section should be considered "possibly incomplete", and requesters + should be prepared to re-query for any damaged or missing RRsets. Note + that truncation of the additional data section might not be signalled + via the TC bit since additional data is often optional (see discussion + in [RFC4472 B]). + + 2.1.5. DNS label compression allows a domain name to be instantiated + only once per DNS message, and then referenced with a two-octet + "pointer" from other locations in that same DNS message (see [RFC1035 + 4.1.4]). If all nameserver names in a message share a common parent + (for example, all ending in ".ROOT-SERVERS.NET"), then more space will + be available for incompressable data (such as nameserver addresses). + + 2.1.6. The query name can be as long as 255 octets of network data. In + this worst case scenario, the question section will be 259 octets in + size, which would leave only 240 octets for the authority and additional + sections (after deducting 12 octets for the fixed length header.) + + 2.2. ADVICE TO ZONE OWNERS + + 2.2.1. Average and maximum question section sizes can be predicted by + the zone owner, since they will know what names actually exist, and can + measure which ones are queried for most often. Note that if the zone + contains any wildcards, it is possible for maximum length queries to + require positive responses, but that it is reasonable to expect + truncation and TCP retry in that case. For cost and performance + reasons, the majority of requests should be satisfied without truncation + or TCP retry. + + 2.2.2. Some queries to non-existing names can be large, but this is not + a problem because negative responses need not contain any answer, + authority or additional records. See [RFC2308 2.1] for more information + about the format of negative responses. + + 2.2.3. The minimum useful number of name servers is two, for redundancy + (see [RFC1034 4.1]). A zone's name servers should be reachable by all + IP transport protocols (e.g., IPv4 and IPv6) in common use. + + 2.2.4. The best case is no truncation at all. This is because many + requesters will retry using TCP immediately, or will automatically re- + query for RRsets that are possibly truncated, without considering + whether the omitted data was actually necessary. + + + + + + Expires January 2007 [Page 3] + + INTERNET-DRAFT August 2006 RESPSIZE + + + 2.3. ADVICE TO SERVER IMPLEMENTORS + + 2.3.1. In case of multi-homed name servers, it is advantageous to + include an address record from each of several name servers before + including several address records for any one name server. If address + records for more than one transport (for example, A and AAAA) are + available, then it is advantageous to include records of both types + early on, before the message is full. + + 2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type, + class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME). + Each A RR will require 16 octets, and each AAAA RR will require 28 + octets. + + 2.3.3. While DNS distinguishes between necessary and optional resource + records, this distinction is according to protocol elements necessary to + signify facts, and takes no official notice of protocol content + necessary to ensure correct operation. For example, a nameserver name + that is in or below the zone cut being described by a delegation is + "necessary content," since there is no way to reach that zone unless the + parent zone's delegation includes "glue records" describing that name + server's addresses. + + 2.3.4. It is also necessary to distinguish between "explicit truncation" + where a message could not contain enough records to convey its intended + meaning, and so the TC bit has been set, and "silent truncation", where + the message was not large enough to contain some records which were "not + required", and so the TC bit was not set. + + 2.3.5. A delegation response should prioritize glue records as follows. + + first + All glue RRsets for one name server whose name is in or below the + zone being delegated, or which has multiple address RRsets (currently + A and AAAA), or preferably both; + + second + Alternate between adding all glue RRsets for any name servers whose + names are in or below the zone being delegated, and all glue RRsets + for any name servers who have multiple address RRsets (currently A + and AAAA); + + thence + All other glue RRsets, in any order. + + + + + Expires January 2007 [Page 4] + + INTERNET-DRAFT August 2006 RESPSIZE + + + Whenever there are multiple candidates for a position in this priority + scheme, one should be chosen on a round-robin or fully random basis. + + The goal of this priority scheme is to offer "necessary" glue first, + avoiding silent truncation for this glue if possible. + + 2.3.6. If any "necessary content" is silently truncated, then it is + advisable that the TC bit be set in order to force a TCP retry, rather + than have the zone be unreachable. Note that a parent server's proper + response to a query for in-child glue or below-child glue is a referral + rather than an answer, and that this referral MUST be able to contain + the in-child or below-child glue, and that in outlying cases, only EDNS + or TCP will be large enough to contain that data. + + 3 - Analysis + + 3.1. An instrumented protocol trace of a best case delegation response + follows. Note that 13 servers are named, and 13 addresses are given. + This query was artificially designed to exactly reach the 512 octet + limit. + + ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 + ;; QUERY SECTION: + ;; [23456789.123456789.123456789.\ + 123456789.123456789.123456789.com A IN] ;; @80 + + ;; AUTHORITY SECTION: + com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 + com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 + com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 + com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 + com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 + com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 + com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 + com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 + com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 + com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 + com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 + com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 + com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 + + + + + + + + + Expires January 2007 [Page 5] + + INTERNET-DRAFT August 2006 RESPSIZE + + + ;; ADDITIONAL SECTION: + A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 + B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 + C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 + D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 + E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 + F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 + G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 + H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 + I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 + J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 + K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 + L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 + M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 + + ;; MSG SIZE sent: 80 rcvd: 512 + + 3.2. For longer query names, the number of address records supplied will + be lower. Furthermore, it is only by using a common parent name (which + is GTLD-SERVERS.NET in this example) that all 13 addresses are able to + fit, due to the use of DNS compression pointers in the last 12 + occurances of the parent domain name. The following output from a + response simulator demonstrates these properties. + + % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br + a.dns.br requires 10 bytes + b.dns.br requires 4 bytes + c.dns.br requires 4 bytes + d.dns.br requires 4 bytes + # of NS: 4 + For maximum size query (255 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 3 (yellow) + preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) + For average size query (64 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 4 (green) + preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) + + + + + + + + + + + Expires January 2007 [Page 6] + + INTERNET-DRAFT August 2006 RESPSIZE + + + % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int + ns-ext.isc.org requires 16 bytes + ns.psg.com requires 12 bytes + ns.ripe.net requires 13 bytes + ns.eu.int requires 11 bytes + # of NS: 4 + For maximum size query (255 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 3 (yellow) + preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) + For average size query (64 byte): + only A is considered: # of A is 4 (green) + A and AAAA are considered: # of A+AAAA is 4 (green) + preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green) + + (Note: The response simulator program is shown in Section 5.) + + Here we use the term "green" if all address records could fit, or + "yellow" if two or more could fit, or "orange" if only one could fit, or + "red" if no address record could fit. It's clear that without a common + parent for nameserver names, much space would be lost. For these + examples we use an average/common name size of 15 octets, befitting our + assumption of GTLD-SERVERS.NET as our common parent name. + + We're assuming a medium query name size of 64 since that is the typical + size seen in trace data at the time of this writing. If + Internationalized Domain Name (IDN) or any other technology which + results in larger query names be deployed significantly in advance of + EDNS, then new measurements and new estimates will have to be made. + + 4 - Conclusions + + 4.1. The current practice of giving all nameserver names a common parent + (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS + responses and allows for more nameservers to be enumerated than would + otherwise be possible, since the common parent domain name only appears + once in a DNS message and is referred to via "compression pointers" + thereafter. + + 4.2. If all nameserver names for a zone share a common parent, then it + is operationally advisable to make all servers for the zone thus served + also be authoritative for the zone of that common parent. For example, + the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively + for the ROOT-SERVERS.NET. This is to ensure that the zone's servers + always have the zone's nameservers' glue available when delegating, and + + + + Expires January 2007 [Page 7] + + INTERNET-DRAFT August 2006 RESPSIZE + + + will be able to respond with answers rather than referrals if a + requester who wants that glue comes back asking for it. In this case + the name server will likely be a "stealth server" -- authoritative but + unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more + information about stealth servers. + + 4.3. Thirteen (13) is the effective maximum number of nameserver names + usable traditional (non-extended) DNS, assuming a common parent domain + name, and given that implicit referral response truncation is + undesirable in the average case. + + 4.4. Multi-homing of name servers within a protocol family is + inadvisable since the necessary glue RRsets (A or AAAA) are atomically + indivisible, and will be larger than a single resource record. Larger + RRsets are more likely to lead to or encounter truncation. + + 4.5. Multi-homing of name servers across protocol families is less + likely to lead to or encounter truncation, partly because multiprotocol + clients are more likely to speak EDNS which can use a larger response + size limit, and partly because the resource records (A and AAAA) are in + different RRsets and are therefore divisible from each other. + + 4.6. Name server names which are at or below the zone they serve are + more sensitive to referral response truncation, and glue records for + them should be considered "less optional" than other glue records, in + the assembly of referral responses. + + 4.7. If a zone is served by thirteen (13) name servers having a common + parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a + single address record in some protocol family (e.g., an A RR), then all + thirteen name servers or any subset thereof could multi-home in a second + protocol family by adding a second address record (e.g., an AAAA RR) + without reducing the reachability of the zone thus served. + + 5 - Source Code + + #!/usr/bin/perl + # + # SYNOPSIS + # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... + # if all queries are assumed to have a same zone suffix, + # such as "jp" in JP TLD servers, specify it in -z option + # + use strict; + use Getopt::Std; + + + + Expires January 2007 [Page 8] + + INTERNET-DRAFT August 2006 RESPSIZE + + + my ($sz_msg) = (512); + my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28); + my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2); + my (%namedb, $name, $nssect, %opts, $optz); + my $n_ns = 0; + + getopt('z', %opts); + if (defined($opts{'z'})) { + server_name_len($opts{'z'}); # just register it + } + + foreach $name (@ARGV) { + my $len; + $n_ns++; + $len = server_name_len($name); + print "$name requires $len bytes\n"; + $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + + $sz_rdlen + $len; + } + print "# of NS: $n_ns\n"; + arsect(255, $nssect, $n_ns, "maximum"); + arsect(64, $nssect, $n_ns, "average"); + + sub server_name_len { + my ($name) = @_; + my (@labels, $len, $n, $suffix); + + $name =~ tr/A-Z/a-z/; + @labels = split(/\./, $name); + $len = length(join('.', @labels)) + 2; + for ($n = 0; $#labels >= 0; $n++, shift @labels) { + $suffix = join('.', @labels); + return length($name) - length($suffix) + $sz_ptr + if (defined($namedb{$suffix})); + $namedb{$suffix} = 1; + } + return $len; + } + + sub arsect { + my ($sz_query, $nssect, $n_ns, $cond) = @_; + my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect); + $ansect = $sz_query + 1 + $sz_type + $sz_class; + $space = $sz_msg - $sz_header - $ansect - $nssect; + $n_a = atmost(int($space / $sz_rr_a), $n_ns); + + + + Expires January 2007 [Page 9] + + INTERNET-DRAFT August 2006 RESPSIZE + + + $n_a_aaaa = atmost(int($space + / ($sz_rr_a + $sz_rr_aaaa)), $n_ns); + $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) + / $sz_rr_aaaa), $n_ns); + printf "For %s size query (%d byte):\n", $cond, $sz_query; + printf " only A is considered: "; + printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); + printf " A and AAAA are considered: "; + printf "# of A+AAAA is %d (%s)\n", + $n_a_aaaa, &judge($n_a_aaaa, $n_ns); + printf " preferred-glue A is assumed: "; + printf "# of A is %d, # of AAAA is %d (%s)\n", + $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns); + } + + sub judge { + my ($n, $n_ns) = @_; + return "green" if ($n >= $n_ns); + return "yellow" if ($n >= 2); + return "orange" if ($n == 1); + return "red"; + } + + sub atmost { + my ($a, $b) = @_; + return 0 if ($a < 0); + return $b if ($a > $b); + return $a; + } + + 6 - Security Considerations + + The recommendations contained in this document have no known security + implications. + + 7 - IANA Considerations + + This document does not call for changes or additions to any IANA + registry. + + 8 - Acknowledgement + + The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews + for their valuable comments and suggestions. + + + + + Expires January 2007 [Page 10] + + INTERNET-DRAFT August 2006 RESPSIZE + + + This work was supported by the US National Science Foundation (research + grant SCI-0427144) and DNS-OARC. + + 9 - References + + [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities", + RFC1034, November 1987. + + [RFC1035] Mockapetris, P.V., "Domain names - Implementation and + Specification", RFC1035, November 1987. + + [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - + Application and Support", RFC1123, October 1989. + + [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC1996, August 1996. + + [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification", + RFC2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671, + August 1999. + + [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration + and Issues with IPV6 DNS", April 2006. + + 10 - Authors' Addresses + + Paul Vixie + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + +1 650 423 1301 + vixie@isc.org + + Akira Kato + University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + +81 3 5841 2750 + kato@wide.ad.jp + + + + + Expires January 2007 [Page 11] + + INTERNET-DRAFT August 2006 RESPSIZE + + + Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors retain + all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR + IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in this + document or the extent to which any license under such rights might or + might not be available; nor does it represent that it has made any + independent effort to identify any such rights. Information on the + procedures with respect to rights in RFC documents can be found in BCP + 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an attempt + made to obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can be + obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary rights + that may cover technology that may be required to implement this + standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + Expires January 2007 [Page 12] + + diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt new file mode 100644 index 0000000..c6ec7e4 --- /dev/null +++ b/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/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt new file mode 100644 index 0000000..3353b3b --- /dev/null +++ b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt @@ -0,0 +1,1588 @@ + + Mark Foster +Internet Draft Tom McGarry +Document: <draft-ietf-enum-e164-gstn-np-05.txt> James Yu + NeuStar, Inc. +Category: Informational June 24, 2002 + + + Number Portability in the GSTN: An Overview + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [RFC]. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of + six months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + Copyright Notice + + Copyright (C) The Internet Society (2002). All rights reserved. + + + Abstract + + This document provides an overview of E.164 telephone number + portability (NP) in the Global Switched Telephone Network (GSTN). + NP is a regulatory imperative seeking to liberalize local telephony + service competition, by enabling end-users to retain telephone + numbers while changing service providers. NP changes the + fundamental nature of a dialed E.164 number from a hierarchical + physical routing address to a virtual address, thereby requiring the + transparent translation of the later to the former. In addition, + there are various regulatory constraints that establish relevant + parameters for NP implementation, most of which are not network + technology specific. Consequently, the implementation of NP + behavior consistent with applicable regulatory constraints, as well + as the need for interoperation with the existing GSTN NP + implementations, are relevant topics for numerous areas of IP + telephony work-in-progress at IETF. + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 1] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + Table of Contents + + 1. Introduction ............................................... 2 + 2. Abbreviations and Acronyms ................................. 4 + 3. Types of Number Portability ................................ 5 + 4. Service Provider Number Portability Schemes ................ 7 + 4.1 All Call Query (ACQ) .................................. 7 + 4.2 Query on Release (QoR) ................................ 8 + 4.3 Call Dropback ......................................... 9 + 4.4 Onward Routing (OR) ................................... 9 + 4.5 Comparisons of the Four Schemes ....................... 10 + 5. Database Queries in the NP Environment ..................... 11 + 5.1 U.S. and Canada ....................................... 12 + 5.2 Europe ................................................ 13 + 6. Call Routing in the NP Environment ......................... 14 + 6.1 U.S. and Canada ....................................... 14 + 6.2 Europe ................................................ 15 + 7. NP Implementations for Geographic E.164 Numbers ............ 17 + 8. Number Conservation Method Enabled By NP ................... 20 + 8.1 Block Pooling ......................................... 20 + 8.2 ITN Pooling ........................................... 21 + 9. Potential Implications ..................................... 21 + 10. Security Considerations .................................... 24 + 11. IANA Considerations ........................................ 24 + 12. Normative References ....................................... 24 + 13. Informative References ..................................... 25 + 14. Acknowledgement ............................................ 25 + 15. AuthorsË Addresses ......................................... 25 + + + +1. Introduction + + This document provides an overview of E.164 telephone number + portability in the Global Switched Telephone Network (GSTN). There + are considered to be three types of number portability (NP): service + provider portability (SPNP), location portability (not to be + confused with terminal mobility), and service portability. + + Service provider portability (SPNP), the focus of the present draft, + is a regulatory imperative in many countries seeking to liberalize + telephony service competition, especially local service. + Historically, local telephony service (as compared to long distance + or international service) has been regulated as a utility-like form + of service. While a number of countries had begun liberalization + (e.g. privatization, de-regulation, or re-regulation) some years + ago, the advent of NP is relatively recent (since ~1995). + + E.164 numbers can be non-geographic and geographic numbers. Non- + geographic numbers do not reveal the locations information of those + numbers. Geographic E.164 numbers were intentionally designed as + hierarchical routing addresses which could systematically be digit- + analyzed to ascertain the country, serving network provider, serving + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 2] + +Number Portability in the GSTN: An Overview June 24, 2002 + + end-office switch, and specific line of the called party. As such, + without NP a subscriber wishing to change service providers would + incur a number change as a consequence of being served off of a + different end-office switch operated by the new service provider. + The cost and convenience impact to the subscriber of changing + numbers is seen as barrier to competition. Hence NP has become + associated with GSTN infrastructure enhancements associated with a + competitive environment driven by regulatory directives. + + Forms of SPNP have been deployed or are being deployed widely in the + GSTN in various parts of the world, including the U.S., Canada, + Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). + Other regions, such as South America (e.g. Brazil) are actively + considering it. + + Implementation of NP within a national telephony infrastructure + entails potentially significant changes to numbering administration, + network element signaling, call routing and processing, billing, + service management, and other functions. + + NP changes the fundamental nature of a dialed E.164 number from a + hierarchical physical routing address to a virtual address. NP + implementations attempt to encapsulate the impacts to the GSTN and + make NP transparent to subscribers by incorporating a translation + function to map a dialed, potentially ported E.164 address, into a + network routing address (either a number prefix or another E.164 + address) which can be hierarchically routed. + + This is roughly analogous to the use of network address translation + on IP addresses to enable IP address portability by containing the + impact of the address change to the edge of the network and retain + the use of CIDR blocks in the core which can be route aggregated by + the network service provider to the rest of the internet. + + NP bifurcates the historical role of a subscriberËs E.164 address + into two or more data elements (a dialed or virtual address, and a + network routing address) that must be made available to network + elements through an NP translations database, carried by forward + call signaling, and recorded on call detail records. Not only is + call processing and routing affected, but also so is SS7/C7 + messaging. A number of TCAP-based SS7 messaging sets utilize an + E.164 address as an application-level network element address in the + global title address (GTA) field of the SCCP message header. + Consequently, SS7/C7 signaling transfer points (STPs) and gateways + need to be able to perform n-digit global title translation (GTT) to + translate a dialed E.164 address into its network address + counterpart via the NP database. + + In addition, there are various national regulatory constraints that + establish relevant parameters for NP implementation, most of which + are not network technology specific. Consequently, implementations + of NP behavior in IP telephony consistent with applicable regulatory + constraints, as well as the need for interoperation with the + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 3] + +Number Portability in the GSTN: An Overview June 24, 2002 + + existing GSTN NP implementations, are relevant topics for numerous + areas of IP telephony work-in-progress at IETF. + + This document describes three types of number portability and the + four schemes that have been standardized to support SPNP for + geographic E.164 numbersspecifically. Following that, specific + information regarding the call routing and database query + implementations are described for several regions (North American + and Europe) and industries (wireless vs. wireline). The Number + Portability Database (NPDB) interfaces and the call routing schemes + that are used in the North America and Europe are described to show + the variety of standards that may be implemented worldwide. A + glance of the NP implementations worldwide is provided. Number + pooling is briefly discussed to show how NP is being enhanced in the + U.S. to conserve North American area codes. The conclusion briefly + touches the potential impacts of NP on IP & Telecommunications + Interoperability. Appendix A provides some specific technical and + regulatory information on NP in North America. Appendix B describes + the number portability administration process that manages the + number portability database in North America. + + +2. Abbreviations and Acronyms + + ACQ All Call Query + AIN Advanced Intelligent Network + AMPS Advanced Mobile Phone System + ANSI American National Standards Institute + CDMA Code Division Multiple Access + CdPA Called Party Address + CdPN Called Party Number + CH Code Holder + CMIP Common Management Information Protocol + CS1 Capability Set 1 + CS2 Capability Set 2 + DN Directory Number + DNS Domain Name System + ETSI European Technical Standards Institute + FCI Forward Call Indicator + GAP Generic Address Parameter + GMSC Gateway Mobile Services Switching Center or Gateway Mobile + Switching Center + GSM Global System for Mobile Communications + GSTN Global Switched Telephone Network + GW Gateways + HLR Home Location Register + IAM Initial Address Message + IETF Internet Engineering Task Force + ILNP Interim LNP + IN Intelligent Network + INAP Intelligent Network Application Part + INP Interim NP + IP Internet Protocol + IS-41 Interim Standards Number 41 + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 4] + +Number Portability in the GSTN: An Overview June 24, 2002 + + ISDN Integrated Services Digital Network + ISUP ISDN User Part + ITN Individual Telephony Number + ITU International Telecommunication Union + ITU-TS ITU-Telecommunication Sector + LDAP Lightweight Directory Access Protocol + LEC Local Exchange Carrier + LERG Local Exchange Routing Guide + LNP Local Number Portability + LRN Location Routing Number + MAP Mobile Application Part + MNP Mobile Number Portability + MSRN Mobile Station Roaming Number + MTP Message Transfer Part + NANP North American Numbering Plan + NP Number Portability + NPDB Number Portability Database + NRN Network Routing Number + OR Onward Routing + OSS Operation Support System + PCS Personal Communication Services + PNTI Ported Number Translation Indicator + PODP Public Office Dialing Plan + PUC Public Utility Commission + QoR Query on Release + RN Routing Number + RTP Return to Pivot + SCCP Signaling Connection Control Part + SCP Service Control Point + SIP Session Initiation Protocol + SMR Special Mobile Radio + SMS Service Management System + SPNP Service Provider Number Portability + SRF Signaling Relaying Function + SRI Send Routing Information + SS7 Signaling System Number 7 + STP Signaling Transfer Point + TCAP Transaction Capabilities Application Part + TDMA Time Division Multiple Access + TN Telephone Number + TRIP Telephony Routing Information Protocol + URL Universal Resource Locator + U.S. United States + + +3. Types of Number Portability + + As there are several types of E.164 numbers (telephone numbers, or + just TN) in the GSTN, there are correspondingly several types of + E.164 NP in the GSTN. First there are so-call non-geographic E.164 + numbers, commonly used for service-specific applications such as + freephone (800 or 0800). Portability of these numbers is called + non-geographic number portability (NGNP). NGNP, for example, was + deployed in the U.S. in 1986-92. + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 5] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + Geographic number portability, which includes traditional fixed or + wireline numbers as well as mobile numbers which are allocated out + of geographic number range prefixes, is called NP or GNP or in the + U.S. local number portability (LNP). + + Number portability allows the telephony subscribers in the Global + Switched Telephone Network (GSTN) to keep their phone numbers when + they change their service providers or subscribed services, or when + they move to a new location. + + The ability to change the service provider while keeping the same + phone number is called service provider portability (SPNP) also + known as "operator portability." + + The ability to change the subscriberËs fixed service location while + keeping the same phone number is called location portability. + + The ability to change the subscribed services (e.g., from the plain + old telephone service to Integrated Services Digital Network (ISDN) + services) while keeping the same phone number is called service + portability. Another aspect of service portability is to allow the + subscribers to enjoy the subscribed services in the same way when + they roam outside their home networks as is supported by the + cellular/wireless networks. + + In addition, mobile number portability (MNP) refers to specific NP + implementation in mobile networks either as part of a broader NP + implementation in the GSTN or on a stand-alone basis. Where + interoperation of LNP and MNP is supported, service portability + between fixed and mobile service types is possible. + + At present, SPNP has been the primary form of NP deployed due to its + relevance in enabling local service competition. + + Also in use in the GSTN are the terms interim NP (INP) or Interim + LNP (ILNP) and true NP. Interim NP usually refers to the use of + remote call forwarding-like measures to forward calls to ported + numbers through the donor network to the new service network. These + are considered interim relative to true NP, which seeks to remove + the donor network or old service provider from the call or signaling + path altogether. Often the distinction between interim and true NP + is a national regulatory matter relative to the + technical/operational requirements imposed on NP in that country. + + Implementations of true NP in certain countries (e.g. U.S., Canada, + Spain, Belgium, Denmark) may pose specific requirements for IP + telephony implementations as a result of regulatory and industry + requirements for providing call routing and signaling independent of + the donor network or last previous serving network. + + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 6] + +Number Portability in the GSTN: An Overview June 24, 2002 + + +4. Service Provider Number Portability Schemes + + Four schemes can be used to support service provider portability and + are briefly described below. But first, some further terms are + introduced. + + The donor network is the network that first assigned a telephone + number (e.g., TN +1-202-533-1234) to a subscriber, out of a number + range administratively (e.g., +1 202-533) assigned to it. The + current service provider (new SP) or new serving network is the + network that currently serves the ported number. The old serving + network (or old SP) is the network that previously served the ported + number before the number was ported to the new serving network. + Since a TN can port a number of times, the old SP is not necessarily + the same as the donor network, except for the first time the TN + ports away, or if the TN ports back into the donor network and away + again. While the new SP and old SP roles are transitory as a TN + ports around, the donor network is always the same for any + particular TN based on the service provider to whom the subtending + number range was administratively assigned. See the discussion + below on number pooling, as this enhancement to NP further + bifurcates the role of donor network into two (the number range or + code holder network, and the block holder network). + + To simplify the illustration, all the transit networks are ignored, + the originating or donor network is the one that performs the + database queries or call redirection, and the dialed directory + number (TN) has been ported out of the donor network before. + + It is assumed that the old serving network, the new serving network + and the donor network are different networks so as to show which + networks are involved in call handling and routing and database + queries in each of four schemes. Please note that the port of the + number (process of moving it from one network to another) happened + prior to the call setup and is not included in the call steps. + Information carried in the signaling messages to support each of the + four schemes is not discussed to simplify the explanation. + + +4.1 All Call Query (ACQ) + + Figure 1 shows the call steps for the ACQ scheme. Those call steps + are as follows: + + (1) The Originating Network receives a call from the caller and + sends a query to a centrally administered Number Portability + Database (NPDB), a copy of which is usually resident on a + network element within its network or through a third party + provider. + (2) The NPDB returns the routing number associated with the dialed + directory number. The routing number is discussed later in + Section 6. + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 7] + +Number Portability in the GSTN: An Overview June 24, 2002 + + (3) The Originating Network uses the routing number to route the + call to the new serving network. + + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | ported | Old Serv. | + | NPDB | +-------->| Network |<------------| Network | + +-------------+ | +-----------+ +-----------+ + ^ | | + | | | + 1| | 3.| + | | 2. | + | | | + | v | + +----------+ | +----------+ +----------+ + | Orig. |------+ | Donor | | Internal | + | Network | | Network | | NPDB | + +----------+ +----------+ +----------+ + + + Figure 1 - All Call Query (ACQ) Scheme. + + +4.2 Query on Release (QoR) + + Figure 2 shows the call steps for the QoR scheme. Those call steps + are as follows: + + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | ported | Old Serv. | + | NPDB | | Network |<------------| Network | + +-------------+ +-----------+ +-----------+ + ^ | ^ + | | 4. | + 3.| | 5. | + | | +----------------------+ + | | | + | v | + +----------+ 2. +----------+ +----------+ + | Orig. |<---------------| Donor | | Internal | + | Network |--------------->| Network | | NPDB | + +----------+ 1. +----------+ +----------+ + + + Figure 2 - Query on Release (QoR) Scheme. + + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network releases the call and indicates that the + dialed directory number has been ported out of that switch. + (3) The Originating Network sends a query to its copy of the + centrally administered NPDB. + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 8] + +Number Portability in the GSTN: An Overview June 24, 2002 + + (4) The NPDB returns the routing number associated with the dialed + directory number. + (5) The Originating Network uses the routing number to route the + call to the new serving network. + + +4.3 Call Dropback + + Figure 3 shows the call steps for the Dropback scheme. This scheme + is also known as "Return to Pivot (RTP)." Those call steps are as + follows: + + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network detects that the dialed directory number has + been ported out of the donor switch and checks with an internal + network-specific NPDB. + (3) The internal NPDB returns the routing number associated with the + dialed directory number. + (4) The donor network releases the call by providing the routing + number. + (5) The Originating Network uses the routing number to route the + call to the new serving network. + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | porting | Old Serv. | + | NPDB | | Network |<------------| Network | + +-------------+ +-----------+ +-----------+ + /\ + | + 5. | + +------------------------+ + | + | + +----------+ 4. +----------+ 3. +----------+ + | Orig. |<---------------| Donor |<----------| Internal | + | Network |--------------->| Network |---------->| NPDB | + +----------+ 1. +----------+ 2. +----------+ + + + Figure 3 - Dropback Scheme. + + +4.4 Onward Routing (OR) + + Figure 4 shows the call steps for the OR scheme. Those call steps + are as follows: + + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network detects that the dialed directory number has + been ported out of the donor switch and checks with an internal + network-specific NPDB. + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 9] + +Number Portability in the GSTN: An Overview June 24, 2002 + + (3) The internal NPDB returns the routing number associated with the + dialed directory number. + (4) The donor network uses the routing number to route the call to + the new serving network. + + + +-------------+ +-----------+ Number +-----------+ + | Centralized | | New Serv. | porting | Old Serv. | + | NPDB | | Network |<------------| Network | + +-------------+ +-----------+ +-----------+ + /\ + | + 4.| + | + +----------+ +----------+ 3. +----------+ + | Orig. | | Donor |<----------| Internal | + | Network |--------------->| Network |---------->| NPDB | + +----------+ 1. +----------+ 2. +----------+ + + + Figure 4 - Onward Routing (OR) Scheme. + +4.5 Comparisons of the Four Schemes + + Only the ACQ scheme does not involve the donor network when routing + the call to the new serving network of the dialed ported number. + The other three schemes involve call setup to or signaling with the + donor network. + + Only the OR scheme requires the setup of two physical call segments, + one from the Originating Network to the donor network and the other + from the donor network to the new serving network. The OR scheme is + the least efficient in terms of using the network transmission + facilities. The QoR and Dropback schemes set up calls to the donor + network first but release the call back to the Originating Network + that then initiates a new call to the Current Serving Network. For + the QoR and Dropback schemes, circuits are still reserved one by one + between the Originating Network and the donor network when the + Originating Network sets up the call towards the donor network. + Those circuits are released one by one when the call is released + from the donor network back to the Originating Network. The ACQ + scheme is the most efficient in terms of using the switching and + transmission facilities for the call. + + Both the ACQ and QoR schemes involve Centralized NPDBs for the + Originating Network to retrieve the routing information. + Centralized NPDB means that the NPDB contains ported number + information from multiple networks. This is in contrast to the + internal network-specific NPDB that is used for the Dropback and OR + schemes. The internal NPDB only contains information about the + numbers that were ported out of the donor network. The internal + NPDB can be a stand-alone database that contains information about + all or some ported-out numbers from the donor network. It can also + reside on the donor switch and only contains information about those + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 10] + +Number Portability in the GSTN: An Overview June 24, 2002 + + numbers ported out of the donor switch. In that case, no query to a + stand-alone internal NPDB is required. The donor switch for a + particular phone number is the switch to which the number range is + assigned from which that phone number was originally assigned. + + For example, number ranges in the North American Numbering Plan + (NANP) are usually assigned in the form of central office codes (CO + codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a + switch serving +1-202-533 would typically serve +1-202-533-0000 + through +1-202-533-9999. In major cities, switches usually host + several CO codes. NPA stands for Numbering Plan Area that is also + known as the area code. It is three-digit long and has the format + of NXX where N is any digit from 2 to 9 and X is any digit from 0 to + 9. NXX in the NPA+NXX format is known as the office code that has + the same format as the NPA. When a NPA+NXX code is set as + Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a + "portable NPA+NXX" code. + + Similarly, in other national E.164 numbering plans, number ranges + cover a contiguous range of numbers within that range. Once a + number within that range has ported away from the donor network, all + numbers in that range are considered potentially ported and should + be queried in the NPDB. + + The ACQ scheme has two versions. One version is for the Originating + Network to always query the NPDB when a call is received from the + caller regardless whether the dialed directory number belongs to any + number range that is portable or has at least one number ported out. + The other version is to check whether the dialed directory number + belongs to any number range that is portable or has at least one + number ported out. If yes, an NPDB query is sent. If not, no NPDB + query is sent. The former performs better when there are many + portable number ranges. The latter performs better when there are + not too many portable number ranges at the expense of checking every + call to see whether NPDB query is needed. The latter ACQ scheme is + similar to the QoR scheme except that the QoR scheme uses call setup + and relies on the donor network to indicate "number ported out" + before launching the NPDB query. + + +5. Database Queries in the NP Environment + + As indicated earlier, the ACQ and QoR schemes require that a switch + query the NPDB for routing information. Various standards have been + defined for the switch-to-NPDB interface. Those interfaces with + their protocol stacks are briefly described below. The term "NPDB" + is used for a stand-alone database that may support just one or some + or all of the interfaces mentioned below. The NPDB query contains + the dialed directory number and the NPDB response contains the + routing number. There are certainly other information that is sent + in the query and response. The primary interest is to get the + routing number from the NPDB to the switch for call routing. + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 11] + +Number Portability in the GSTN: An Overview June 24, 2002 + +5.1 U.S. and Canada + + One of the following five NPDB interfaces can be used to query an + NPDB: + + (a) Advanced Intelligent Network (AIN) using the American National + Standards Institute (ANSI) version of the Intelligent Network + Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is + carried on top of the protocol stack that includes the (ANSI) + Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling + Connection Control Part (SCCP), and ANSI Transaction + Capabilities Application Part (TCAP). This interface can be + used by the wireline or wireless switches, is specific to the NP + implementation in North America, and is modeled on the Public + Office Dialing Plan (PODP) trigger defined in the Advanced + Intelligent Network (AIN) 0.1 call model. + + (b) Intelligent Network (IN), which is similar to the one used for + querying the 800 databases. The IN protocol is carried on top + of the protocol stack that includes the ANSI MTP Levels 1 + through 3, ANSI SCCP, and ANSI TCAP. This interface can be used + by the wireline or wireless switches. + + (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the + protocol stack that includes the ANSI MTP Levels 1 through 3, + ANSI SCCP, and ANSI TCAP. This interface can be used by the IS- + 41 based cellular/Personal Communication Services (PCS) wireless + switches (e.g., AMPS, TDMA and CDMA). Cellular systems use + spectrum at 800 MHz range and PCS systems use spectrum at 1900 + MHz range. + + (d) Global System for Mobile Communication Mobile Application Part + (GSM MAP) [GSM], which is carried on top of the protocol stack + that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and + International Telecommunication Union - Telecommunication Sector + (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches + that are based on the GSM technologies. GSM is a series of + wireless standards defined by the European Telecommunications + Standards Institute (ETSI). + + (e) ISUP triggerless translation. NP translations are performed + transparently to the switching network by the signaling network + (e.g. Signaling Transfer Points (STPs) or signaling gateways). + ISUP IAM messages are examined to determine if the CdPN field + has already been translated, and if not, an NPDB query is + performed, and the appropriate parameters in the IAM message + modified to reflect the results of the translation. The + modified IAM message is forwarded by the signaling node on to + the designated DPC in a transparent manner to continue call + setup. The NPDB can be integrated with the signaling node or be + accessed via an API locally or by a query to a remote NPDB using + a proprietary protocol or the schemes described above. + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 12] + +Number Portability in the GSTN: An Overview June 24, 2002 + + Wireline switches have the choice of using either (a), (b), or (e). + IS-41 based wireless switches have the choice of using (a), (b), + (c), or (e). PCS1900 wireless switches have the choice of using + (a), (b), (d), or (e). In the United States, service provider + portability will be supported by both the wireline and wireless + systems, not only within the wireline or wireless domain but also + across the wireline/wireless boundary. However, this is not true in + Europe where service provider portability is usually supported only + within the wireline or wireless domain, not across the + wireline/wireless boundary due to explicit use of service-specific + number range prefixes. The reason is to avoid caller confusion + about the call charge. GSM systems in Europe are assigned + distinctive destination network codes, and the caller pays a higher + charge when calling a GSM directory number. + + +5.2 Europe + + One of the following two interfaces can be used to query an NPDB: + + (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is + carried on top of the protocol stack that includes the ITU-TS + MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. + + (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is + carried on top of the protocol stack that includes the ITU-TS + MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, + and ITU-TS TCAP. + + Wireline switches have the choice of using either (a) or (b); + however, all the implementations in Europe so far are based on CS1. + As indicated earlier that number portability in Europe does not go + across the wireline/wireless boundary. The wireless switches can + also use (a) or (b) to query the NPDBs if those NPDBs contains + ported wireless directory numbers. The term "Mobile Number + Portability (MNP)" is used for the support of service provider + portability by the GSM networks in Europe. + + In most, if not all, cases in Europe, the calls to the wireless + directory numbers are routed to the wireless donor network first. + Over there, an internal NPDB is queried to determine whether the + dialed wireless directory number has been ported out or not. In + this case, the interface to the internal NPDB is not subject to + standardization. + + MNP in Europe can also be supported via MNP Signaling Relay Function + (MNP-SRF). Again, an internal NPDB or a database integrated at the + MNP-SRF is used to modify the SCCP Called Party Address parameter in + the GSM MAP messages so that they can be re-directed to the wireless + serving network. Call routing involving MNP will be explained in + Section 6.2. + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 13] + +Number Portability in the GSTN: An Overview June 24, 2002 + +6. Call Routing in the NP Environment + + This section discusses the call routing after the routing + information has been retrieved either through an NPDB query or an + internal database lookup at the donor switch, or from the Integrated + Services Digital Network User Part (ISUP) signaling message (e.g., + for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it + is the Originating Network that has the routing information and is + ready to route the call. For the OR scheme, it is the donor network + that has the routing information and is ready to route the call. + + A number of triggering schemes may be employed that determine where + in the call path the NPDB query is performed. In the U.S. an ŸN-1÷ + policy is used, which essentially says that for domestic calls, the + originating local carriers performs the query, otherwise, the long + distance carrier is expected to. To ensure independence of the + actual trigger policy employed in any one carrier, forward call + signaling is used to flag that an NPDB query has already been + performed and to therefore suppress any subsequent NP triggers that + may be encountered in downstream switches, in downstream networks. + This allows the earliest able network in the call path to perform + the query without introducing additional costs and call setup delays + were redundant queries performed downstream. + + +6.1 U.S. and Canada + + In the U.S. and Canada, a ten-digit North American Numbering Plan + (NANP) number called Location Routing Number (LRN) is assigned to + every switch involved in NP. In the NANP, a switch is not reachable + unless it has a unique number range (CO code) assigned to it. + Consequently, the LRN for a switch is always assigned out of a CO + code that is assigned to that switch. + + The LRN assigned to a switch currently serving a particular ported + telephone number is returned as the network routing address in the + NPDB response. The service portability scheme that was adopted in + the North America is very often referred to as the LRN scheme or + method. + + LRN serves as a network address for terminating calls served off + that switch using ported numbers. The LRN is assigned by the switch + operator using any of the unique CO codes (NPA+NXX) assigned to that + switch. The LRN is considered a non-dialable address, as the same + 10-digit number value may be assigned to a line on that switch. A + switch may have more than one LRN. + + During call routing/processing, a switch performs an NPDB query to + obtain the LRN associated with the dialed directory number. NPDB + queries are performed for all the dialed directory numbers whose + NPA+NXX codes are marked as portable NPA+NXX at that switch. When + formulating the ISUP Initial Address Message (IAM) to be sent to the + next switch, the switch puts the ten-digit LRN in the ISUP Called + Party Number (CdPN) parameter and the originally dialed directory + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 14] + +Number Portability in the GSTN: An Overview June 24, 2002 + + number in the ISUP Generic Address parameter (GAP). A new code in + the GAP was defined to indicate that the address information in the + GAP is the dialed directory number. A new bit in the ISUP Forward + Call Indicator (FCI) parameter, the Ported Number Translation + Indicator (PNTI) bit, is set to imply that NPDB query has already + been performed. All the switches in the downstream will not perform + the NPDB query if the PNTI bit is set. + + When the terminating switch receives the IAM and sees the PNTI bit + in the FCI parameter set and its own LRN in the CdPN parameter, it + retrieves the originally dialed directory number from the GAP and + uses the dialed directory number to terminate the call. + + A dialed directory number with a portable NPA+NXX does not imply + that directory number has been ported. The NPDBs currently do not + store records for non-ported directory numbers. In that case, the + NPDB will return the same dialed directory number instead of the + LRN. The switch will then set the PNTI bit but keep the dialed + directory number in the CdPN parameter. + + In the real world environment, the Originating Network is not always + the one that performs the NPDB query. For example, it is usually + the long distance carriers that query the NPDBs for long distance + calls. In that case, the Originating Network operated by the local + exchange carrier (LEC) simply routes the call to the long distance + carrier that is to handle that call. A wireless network acting as + the Originating Network can also route the call to the + interconnected local exchange carrier network if it does not want to + support the NPDB interface at its mobile switches. + + +6.2 Europe + + In some European countries, a routing number is prefixed to the + dialed directory number. The ISUP CdPN parameter in the IAM will + contain the routing prefix and the dialed directory number. For + example, United Kingdom uses routing prefixes with the format of + 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks + use the information in the ISUP CdPN parameter to route the call to + the New/Current Serving Network. + + The routing prefix can identify the Current Serving Network or the + Current Serving Switch of a ported number. For the former case, + another query to the "internal" NPDB at the Current Serving Network + is required to identify the Current Serving Switch before routing + the call to that switch. This shields the Current Serving Switch + information for a ported number from the other networks at the + expense of an additional NPDB query. Another routing number, may be + meaningful within the Current Serving Network, will replace the + previously prefixed routing number in the ISUP CdPN parameter. For + the latter case, the call is routed to the Current Serving Switch + without an additional NPDB query. + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 15] + +Number Portability in the GSTN: An Overview June 24, 2002 + + When the terminating switch receives the IAM and sees its own + routing prefix in the CdPN parameter, it retrieves the originally + dialed directory number after the routing prefix, and uses the + dialed directory number to terminate the call. + + The call routing example described above shows one of the three + methods that can be used to transport the Directory Number (DN) and + the Routing Number (RN) in the ISUP IAM message. In addition, some + other information may be added/modified as is listed in the ETSI 302 + 097 document [ETSIISUP], which is based on the ITU-T Recommendation + Q.769.1 [ITUISUP]. The three methods and the enhancements in the + ISUP to support number portability are briefly described below + + (a) Two separate parameters with the CdPN parameter containing the + RN and a new Called Directory Number (CdDN) parameter containing + the DN. A new value for the Nature of Address (NOA) indicator in + the CdPN parameter is defined to indicate that the RN is in the + CdPN parameter. The switches use the CdPN parameter to route the + call as is done today. + + (b) Two separate parameters with the CdPN parameter containing the + DN and a new Network Routing Number (NRN) parameter containing + the RN. This method requires that the switches use the NRN + parameter to route the call. + + (c) Concatenated parameter with the CdPN parameter containing the RN + plus the DN. A new Nature of Address (NOA) indicator in the CdPN + parameter is defined to indicate that the RN is concatenated with + the DN in the CdPN parameter. Some countries may not use new NOA + value because the routing prefix does not overlap with the dialed + directory numbers. But if the routing prefix overlaps with the + dialed directory numbers, a new NOA value must be assigned. For + example, Spain uses "XXXXXX" as the routing prefix to identify + the new serving network and uses a new NOA value of 126. + + There is also a network option to add a new ISUP parameter called + Number Portability Forwarding Information parameter. This parameter + has a four-bit Number Portability Status Indicator field that can + provide an indication whether number portability query is done for + the called directory number and whether the called directory number + is ported or not if the number portability query is done. + + Please note that all those NP enhancements for a ported number can + only be used in the country that defined them. This is because + number portability is supported within a nation. Within each + nation, the telecommunications industry or the regulatory bodies can + decide which method or methods to use. Number portability related + parameters and coding are usually not passed across the national + boundaries unless the interconnection agreements allow that. For + example, a UK routing prefix can only be used in UK, and would cause + routing problem if it appears outside UK. + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 16] + +Number Portability in the GSTN: An Overview June 24, 2002 + + As indicated earlier, an originating wireless network can query the + NPDB and concatenate the RN with DN in the CdPN parameter and route + the call directly to the Current Serving Network. + + If NPDBs do not contain information about the wireless directory + numbers, the call, originated from either a wireline or a wireless + network, will be routed to the Wireless donor network. Over there, + an internal NPDB is queried to retrieve the RN that then is + concatenated with the DN in the CdPN parameter. + + There are several ways of realizing MNP. When MNP-SRF is supported, + the Gateway Mobile Services Switching Center (GMSC) at the wireless + donor network, when receiving a call from the wireline network, can + send the GSM MAP Send Routing Information (SRI) message to the MNP- + SRF. The MNP-SRF interrogates an internal or integrated NPDB for + the RN of the MNP-SRF of the wireless Current Serving Network and + prefixes the RN to the dialed wireless directory number in the + global title address information in the SCCP Called Party Address + (CdPA) parameter. This SRI message will be routed to the MNP-SRF of + the wireless Current Serving Network, which then responds with an + acknowledgement by providing the RN plus the dialed wireless + directory number as the Mobile Station Roaming Number (MSRN). The + GMSC of the wireless donor network formulates the ISUP IAM with the + RN plus the dialed wireless directory number in the CdPN parameter + and routes the call to the wireless Current Serving Network. A GMSC + of the wireless Current Serving Network receives the call and sends + an SRI message to the associated MNP-SRF where the global title + address information of the SCCP CdPA parameter contains only the + dialed wireless directory number. The MNP-SRF then replaces the + global title address information in the SCCP CdPA parameter with the + address information associated with a Home Location Register (HLR) + that hosts the dialed wireless directory number and forwards the + message to that HLR after verifying that the dialed wireless + directory number is a ported-in number. The HLR then returns an + acknowledgement by providing an MSRN for the GMSC to route the call + to the MSC that currently serves the mobile station that is + associated with the dialed wireless directory number. Please see + [MNP] for details and additional scenarios. + + +7. NP Implementations for Geographic E.164 Numbers + + This section shows the known SPNP implementations worldwide. + + +-------------+----------------------------------------------------+ + + Country + SPNP Implementation + + +-------------+----------------------------------------------------+ + + Argentina + Analyzing operative viability now. Will determine + + + + whether portability should be made obligatory + + + + after a technical solution has been determined. + + +-------------+----------------------------------------------------+ + + Australia + NP supported by wireline operators since 11/30/99. + + + + NP among wireless operators in March/April 2000, + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 17] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + + but may be delayed to 1Q01. The access provider + + + + or long distance provider has the obligation to + + + + route the call to the correct destination. The + + + + donor network is obligated to maintain and make + + + + available a register of numbers ported away from + + + + its network. Telstra uses onward routing via an + + + + on-switch solution. + + +-------------+----------------------------------------------------+ + + Austria + Uses onward routing at the donor network. Routing + + + + prefix is "86xx" where "xx" identifies the + + + + recipient network. + + +-------------+----------------------------------------------------+ + + Belgium + ACQ selected by the industry. Routing prefix is + + + + "Cxxxx" where "xxxx" identifies the recipient + + + + switch. Another routing prefix is "C00xx" with "xx"+ + + + identifying the recipient network. Plan to use NOA+ + + + to identify concatenated numbers and abandon the + + + + hexadecimal routing prefix. + + +-------------+----------------------------------------------------+ + + Brazil + Considering NP for wireless users. + + +-------------+----------------------------------------------------+ + + Chile + There has been discussions lately on NP. + + +-------------+----------------------------------------------------+ + + Colombia + There was an Article 3.1 on NP to support NP prior + + + + to December 31, 1999 when NP became technically + + + + possible. Regulator has not yet issued regulations + + + + concerning this matter. + + +-------------+----------------------------------------------------+ + + Denmark + Uses ACQ. Routing number not passed between + + + + operators; however, NOA is set to "112" to + + + + indicate "ported number." QoR can be used based + + + + on bilateral agreements. + + +-------------+----------------------------------------------------+ + + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" + + + + identifies the recipient network and service type. + + +-------------+----------------------------------------------------+ + + France + Uses onward routing. Routing prefix is "Z0xxx" + + + + where "xxx" identifies the recipient switch. + + +-------------+----------------------------------------------------+ + + Germany + The originating network needs to do necessary + + + + rerouting. Operators decide their own solution(s).+ + + + Deutsche Telekom uses ACQ. Routing prefix is + + + + "Dxxx" where "xxx" identifies the recipient + + + + network. + + +-------------+----------------------------------------------------+ + + Hong Kong + Recipient network informs other networks about + + + + ported-in numbers. Routing prefix is "14x" where + + + + "14x" identifies the recipient network, or a + + + + routing number of "4x" plus 7 or 8 digits is used + + + + where "4x" identifies the recipient network and + + + + the rest of digits identify the called party. + + +-------------+----------------------------------------------------+ + + Ireland + Operators choose their own solution but use onward + + + + routing now. Routing prefix is "1750" as the intra-+ + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 18] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + + network routing code (network-specific) and + + + + "1752xxx" to "1759xxx" for GNP where "xxx" + + + + identifies the recipient switch. + + +-------------+----------------------------------------------------+ + + Italy + Uses onward routing. Routing prefix is "C600xxxxx" + + + + where "xxxxx" identifies the recipient switch. + + + + Telecom Italia uses IN solution and other operators+ + + + use on-switch solution. + + +-------------+----------------------------------------------------+ + + Japan + Uses onward routing. Donor switch uses IN to get + + + + routing number. + + +-------------+----------------------------------------------------+ + + Mexico + NP is considered in the Telecom law; however, the + + + + regulator (Cofetel) or the new local entrants have + + + + started no initiatives on this process. + + +-------------+----------------------------------------------------+ + + Netherlands + Operators decide NP scheme to use. Operators have + + + + chosen ACQ or QoR. KPN implemented IN solution + + + + similar to U.S. solution. Routing prefix is not + + + + passed between operators. + + +-------------+----------------------------------------------------+ + + Norway + OR for short-term and ACQ for long-term. QoR is + + + + optional. Routing prefix can be "xxx" with NOA=8, + + + + or "142xx" with NOA=3 where "xxx" or "xx" + + + + identifies the recipient network. + + +------------ +----------------------------------------------------+ + + Peru + Wireline NP may be supported in 2001. + + +-------------+----------------------------------------------------+ + + Portugal + No NP today. + + +-------------+----------------------------------------------------+ + + Spain + Uses ACQ. Telefonica uses QoR within its network. + + + + Routing prefix is "xxyyzz" where "xxyyzz" + + + + identifies the recipient network. NOA is set to + + + + 126. + + +-------------+----------------------------------------------------+ + + Sweden + Standardized the ACQ but OR for operators without + + + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + + + + with NOA=3 where "xxx" identifies the recipient + + + + network. But operators decide NP scheme to use. + + + + Telia uses onward routing between operators. + + +-------------+----------------------------------------------------+ + + Switzerland + Uses OR now and QoR in 2001. Routing prefix is + + + + "980xxx" where "xxx" identifies the recipient + + + + network. + + +-------------+----------------------------------------------------+ + + UK + Uses onward routing. Routing prefix is "5xxxxx" + + + + where "xxxxx" identifies the recipient switch. NOA + + + + is 126. BT uses the dropback scheme in some parts + + + + of its network. + + +-------------+----------------------------------------------------+ + + US + Uses ACQ. "Location Routing Number (LRN)" is used + + + + in the Called Party Number parameter. Called party+ + + + number is carried in the Generic Address Parameter + + + + Use a PNTI indicator in the Forward Call Indicator + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 19] + +Number Portability in the GSTN: An Overview June 24, 2002 + + + + parameter to indicate that NPDB dip has been + + + + performed. + + +-------------+----------------------------------------------------+ + + +8. Number Conservation Methods Enabled by NP + + In addition to porting numbers NP provides the ability for number + administrators to assign numbering resources to operators in smaller + increments. Today it is common for numbering resources to be + assigned to telephone operators in a large block of consecutive + telephone numbers (TNs). For example, in North America each of + these blocks contains 10,000 TNs and is of the format NXX+0000 to + NXX+9999. Operators are assigned a specific NXX, or block. That + operator is referred to as the block holder. In that block there + are 10,000 TNs with line numbers ranging from 0000 to 9999. + + Instead of assigning an entire block to the operator NP allows the + administrator to assign a sub-block or even an individual telephone + number. This is referred to as block pooling and individual + telephone number (ITN) pooling, respectively. + + +8.1 Block Pooling + + Block Pooling refers to the process whereby the number administrator + assigns a range of numbers defined by a logical sub-block of the + existing block. Using North America as an example, block pooling + would allow the administrator to assign sub-blocks of 1,000 TNs to + multiple operators. That is, NXX+0000 to NXX+0999 can be assigned + to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, + NXX-2000 to 2999 can be assigned to operator C, etc. In this + example block pooling divides one block of 10,000 TNs into ten + blocks of 1,000 TNs. + + Porting the sub-blocks from the block holder enables block pooling. + Using the example above operator A is the block holder, as well as, + the holder of the first sub-block, NXX+0000 to NXX+0999. The second + sub-block, NXX+1000 to NXX+1999, is ported from operator A to + operator B. The third sub-block, NXX+2000 to NXX+2999, is ported + from operator A to operator C, and so on. NP administrative + processes and call processing will enable proper and efficient + routing. + + From a number administration and NP administration perspective block + pooling introduces a new concept, that of the sub-block holder. + Block pooling requires coordination between the number + administrator, the NP administrator, the block holder, and the sub- + block holder. Block pooling must be implemented in a manner that + allows for NP within the sub-blocks. Each TN can have a different + serving operator, sub-block holder, and block holder. + + + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 20] + +Number Portability in the GSTN: An Overview June 24, 2002 + +8.2 ITN Pooling + + ITN pooling refers to the process whereby the number administrator + assigns individual telephone numbers to operators. Using the North + American example, one block of 10,000 TNs can be divided into 10,000 + ITNs. ITN is more commonly deployed in freephone services. + + In ITN the block is not assigned to an operator but to a central + administrator. The administrator then assigns ITNs to operators. + NP administrative processes and call processing will enable proper + and efficient routing. + + +9. Potential Implications + + There are three general areas of impact to IP telephony work-in- + progress at IETF: + + - Interoperation between NP in GSTN and IP telephony + - NP implementation or emulation in IP telephony + - Interconnection to NP administrative environment + + A good understanding of how number portability is supported in the + GSTN is important when addressing the interworking issues between + IP-based networks and the GSTN. This is especially important when + the IP-based network needs to route the calls to the GSTN. As shown + in Section 5, there are a variety of standards with various protocol + stacks for the switch-to-NPDB interface. Not only that, the + national variations of the protocol standards make it very + complicated to deal with in a global environment. If an entity in + the IP-based network needs to query those existing NPDBs for routing + number information to terminate the calls to the destination GSTN, + it would be impractical, if not an impossible, job for that entity + to support all those interface standards to access the NPDBs in many + countries. + + Several alternatives may address this particular problem. One + alternative is to use certain entities in the IP-based networks for + dealing with NP query, similar to the International Switches that + are used in the GSTN to interwork different national ISUP + variations. This will force signaling information associated with + the calls to certain NP-capable networks in the terminating GSTN to + be routed to those IP entities that support the NP functions. Those + IP entities then query the NPDBs in the terminating country. This + will limit the number of NPDB interfaces that certain IP entities + need to support. Another alternative can be to define a "common" + interface to be supported by all the NPDBs so that all the IP + entities use that standardized protocol to query them. The + existing NPDBs can support this additional interface, or new NPDBs + can be deployed that contain the same information but support the + common IP interface. The candidates for such a common interface + include Lightweight Directory Access Protocol (LDAP) and SIP + [SIP](e.g., using the SIP redirection capability). Certainly + + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 21] + +Number Portability in the GSTN: An Overview June 24, 2002 + + another possibility is to use interworking function to convert from + one protocol to another. + + IP-based networks can handle the domestic calls between two GSTNs. + If the originating GSTN has performed NPDB query, SIP will need to + transport and make use of some of the ISUP signaling information + even if ISUP signaling may be encapsulated in SIP. Also, IP-based + networks may perform the NPDB queries, as the N-1 carrier. In that + case, SIP also needs to transport the NP related information while + the call is being routed to the destination GSTN. There are three + pieces of NP related information that SIP needs to transport. They + are 1) the called directory number, 2) a routing number, and 3) a + NPDB dip indicator. The NPDB dip indicator is needed so that the + terminating GSTN will not perform another NPDB dip. The routing + number is needed so that it is used to route the call to the + destination network or switch in the destination GSTN. The called + directory number is needed so that the terminating GSTN switch can + terminate the call. When the routing number is present, the NPDB + dip indicator may not be present because there are cases where + routing number is added for routing the call even if NP is not + involved. One issue is how to transport the NP related information + via SIP. The SIP Universal Resource Locator (URL) is one mechanism. + Another better choice may be to add an extension to the "tel" URL + [TEL] that is also supported by SIP. Please see [TELNP] for the + proposed extensions to the "tel" URL to support NP and freephone + service. Those extensions to the "tel" URL will be automatically + supported by SIP because they can be carried as the optional + parameters in the user portion of the "sip" URL. + + For a called directory number that belongs to a country that + supports NP, and if the IP-based network is to perform the NPDB + query, the logical step is to perform the NPDB dip first to retrieve + the routing number and use that routing number to select the correct + IP telephony gateways that can reach the serving switch that serves + the called directory number. Therefore, if the "rn" parameter is + present in the "tel" URL or sip URL in the SIP INVITE message, it + instead of the called directory number should be used for making + routing decisions assuming that no other higher priority routing- + related parameters such as the Ÿcic÷ are present. If "rn" is not + present, then the dialed directory number can be used as the routing + number for making routing decisions. + + Telephony Routing Information Protocol (TRIP) [TRIP] is a policy + driven inter-administrative domain protocol for advertising the + reachability of telephony destinations between location servers, and + for advertising attributes of the routes to those destinations. + With the NP in mind, it is very important to know that it is the + routing number, if present, not the called directory number that + should be used to check against the TRIP tables for making the + routing decisions. + + Overlap signaling exists in the GSTN today. For a call routing from + the originating GSTN to the IP-based network that involves overlap + signaling, NP will impact the call processing within the IP-based + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 22] + +Number Portability in the GSTN: An Overview June 24, 2002 + + networks if they must deal with the overlap signaling. The entities + in the IP-based networks that are to retrieve the NP information + (e.g., the routing number) must collect a complete called directory + number information before retrieving the NP information for a ported + number. Otherwise, the information retrieval won't be successful. + This is an issue for the IP-based networks if the originating GSTN + does not handle the overlap signaling by collecting the complete + called directory number. + + The IETF enum working group is defining the use of Domain Name + System (DNS) for identifying available services associated with a + particular E.164 number [ENUM]. [ENUMPO] outlines the principles + for the operation of a telephone number service that resolves + telephone numbers into Internet domain name addresses and service- + specific directory discovery. [ENUMPO] implements a three-level + approach where the first level is the mapping of the telephone + number delegation tree to the authority to which the number has been + delegated, the second level is the provision of the requested DNS + resource records from a service registrar, and the third level is + the provision of service specific data from the service provider + itself. NP certainly must be considered at the first level because + the telephony service providers do not "own" or control the + telephone numbers under the NP environment; therefore, they may not + be the proper entities to have the authority for a given E.164 + number. Not only that, there is a regulatory requirement on NP in + some countries that the donor network should not be relied on to + reach the delegated authority during the DNS process . The + delegated authority for a given E.164 number is likely to be an + entity designated by the end user that owns/controls a specific + telephone number or one that is designated by the service registrar. + + Since the telephony service providers may have the need to use ENUM + for their network-related services (e.g., map an E.164 number to a + HLR Identifier in the wireless networks), their ENUM records must be + collocated with those of the telephony subscribers. If that is the + case, NP will impact ENUM when a telephony subscriber who has ENUM + service changes the telephony service provider. This is because + that the ENUM records from the new telephony service provider must + replace those from the old telephony service provider. To avoid the + NP impact on ENUM, it is recommended that the telephony service + providers use a different domain tree for their network-related + service. For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a + domain tree different from e164.arpa should be used for Ÿcarrier÷ + ENUM. + + The IP-based networks also may need to support some forms of number + portability in the future if E.164 numbers [E164] are assigned to + the IP-based end users. One method is to assign a GSTN routing + number for each IP-based network domain or entity in a NP-capable + country. This may increase the number of digits in the routing + number to incorporate the IP entities and impact the existing + routing in the GSTN. Another method is to associate each IP entity + with a particular GSTN gateway. At that particular GSTN gateway, + the called directory number then is used to locate the IP-entity + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 23] + +Number Portability in the GSTN: An Overview June 24, 2002 + + that serves that dialed directory number. Yet, another method can + be to assign a special routing number so that the call to an end + user currently served by an IP entity is routed to the nearest GSTN + gateway. The called directory number then is used to locate the IP- + entity that serves that dialed directory number. A mechanism can be + developed or used for the IP-based network to locate the IP entity + that serves a particular dialed directory number. Many other types + of networks use E.164 numbers to identify the end users or terminals + in those networks. Number portability among GSTN, IP-based network + and those various types of networks may also need to be supported in + the future. + + +10. Security Considerations + + This document does not raise any security issues. + + +11. IANA Considerations + + This document introduces no new values for IANA registration. + + +12. Normative References + + [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability - + Operator Services Switching Systems," April 1999. + + [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability - + Switching Systems," April 1999. + + [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability + Database and Global Title Translation," April 1999. + + [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number + portability Capability set 1 requirements for service provider + portability (All call query and onward routing)," May 1998. + + [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number + portability -Capability set 2 requirements for service provider + portability (Query on release and Dropback)," March 1999. + + [E164] ITU-T Recommendation E.164, "The International Public + Telecommunications Numbering Plan," 1997. + + [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. + + [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital + Network (ISDN); Signalling System No.7 (SS7); ISDN User Part + (ISUP); Enhancement for support of Number Portability (NP) + [ITU-T Recommendation Q.769.1 (2000), modified] + + [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase + 2+); Mobile Application Part (MAP) specification". + +Foster,McGarry,Yu Expired on December 23, 2002 [Page 24] + +Number Portability in the GSTN: An Overview March 1, 2002 + + + + [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for + Wireless Number Portability Phase II (December 1998)"Number + Portability Network Support," April 1998. + + [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - + ISDN User Part Enhancements for the Support of Number + Portability," December 1999. + + [MNP] ETSI EN 301 716 (2000-10) European Standard + (Telecommunications series) Digital cellular telecommunications + system (Phase 2+); Support of Mobile Number Portability (MNP); + Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 + Release 1998). + + [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- + Revision 3," October 1996. + + +13. Informative References + + [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific + Provisioning: Principles of Operations," draft-ietf-enum- + operation-02.txt, February 23, 2001. + + [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: + Session Initiation Protocol," February 27, 2002. + + [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis- + 04.txt, "URIs for Telephone Calls," May 24, 2002. + + [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL + to support Number Portability and Freephone Service," June 14, + 2002. + + [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony + Routing Information Protocol (TRIP)," January 2002. + + +14. Acknowledgment + + The authors would like to thank Monika Muench for providing + information on ISUP and MNP. + + +15. Authors' Addresses + + Mark D. Foster + NeuStar, Inc. + 1120 Vermont Avenue, NW, + Suite 400 + Washington, D.C. 20005 + United States + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 25] + +Number Portability in the GSTN: An Overview March 1, 2002 + + + + Phone: +1-202-533-2800 + Fax: +1-202-533-2987 + Email: mark.foster@neustar.biz + + Tom McGarry + NeuStar, Inc. + 1120 Vermont Avenue, NW, + Suite 400 + Washington, D.C. 20005 + United States + + Phone: +1-202-533-2810 + Fax: +1-202-533-2987 + Email: tom.mcgarry@neustar.biz + + James Yu + NeuStar, Inc. + 1120 Vermont Avenue, NW, + Suite 400 + Washington, D.C. 20005 + United States + + Phone: +1-202-533-2814 + Fax: +1-202-533-2987 + Email: james.yu@neustar.biz + + + +Full Copyright Statement + + "Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 26] + +Number Portability in the GSTN: An Overview March 1, 2002 + + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 27] +
\ No newline at end of file diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt new file mode 100644 index 0000000..2d5c87e --- /dev/null +++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt @@ -0,0 +1,1200 @@ + + + + + + +IPv6 Working Group John Loughney (ed) +Internet-Draft Nokia + January 14, 2004 + +Expires: July 14, 2004 + + + + IPv6 Node Requirements + draft-ietf-ipv6-node-requirements-08.txt + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + + + + + +Loughney (editor) February 16, 2004 [Page 1] + + + + + +Internet-Draft + + +Table of Contents + + 1. Introduction + 1.1 Requirement Language + 1.2 Scope of this Document + 1.3 Description of IPv6 Nodes + 2. Abbreviations Used in This Document + 3. Sub-IP Layer + 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + 3.2 IP version 6 over PPP - RFC2472 + 3.3 IPv6 over ATM Networks - RFC2492 + 4. IP Layer + 4.1 Internet Protocol Version 6 - RFC2460 + 4.2 Neighbor Discovery for IPv6 - RFC2461 + 4.3 Path MTU Discovery & Packet Size + 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + 4.5 Addressing + 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + 5. Transport and DNS + 5.1 Transport Layer + 5.2 DNS + 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + 6. IPv4 Support and Transition + 6.1 Transition Mechanisms + 7. Mobility + 8. Security + 8.1 Basic Architecture + 8.2 Security Protocols + 8.3 Transforms and Algorithms + 8.4 Key Management Methods + 9. Router Functionality + 9.1 General + 10. Network Management + 10.1 MIBs + 11. Security Considerations + 12. References + 12.1 Normative + 12.2 Non-Normative + 13. Authors and Acknowledgements + 14. Editor's Address + Notices + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 2] + + + + + +Internet-Draft + + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but all IPv6 nodes can be + expected to implement the mandatory requirements listed in this + document. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. In case of any conflicting text, + this document takes less precedence than the normative RFCs, unless + additional clarifying text is included in this document. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + +1.1 Requirement Language + + 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 [RFC-2119]. + +1.2 Scope of this Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes, in order + to ensure interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3 Description of IPv6 Nodes + + From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we + have the following definitions: + + Description of an IPv6 Node + + + + +Loughney (editor) February 16, 2004 [Page 3] + + + + + +Internet-Draft + + + - a device that implements IPv6 + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed to + itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + + +Loughney (editor) February 16, 2004 [Page 4] + + + + + +Internet-Draft + + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2 IP version 6 over PPP - RFC2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- + 2472]. + +3.3 IPv6 over ATM Networks - RFC2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1 Internet Protocol Version 6 - RFC2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receving IPv6 packets; forwarding functionality MAY be + supported + + RFC 2460 specifies extension headers and the processing for these + headers. + + + +Loughney (editor) February 16, 2004 [Page 5] + + + + + +Internet-Draft + + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload. [RFC-2460] + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] caused by them. + +4.2 Neighbor Discovery for IPv6 - RFC2461 + + Neighbor Discovery SHOULD be supported. RFC 2461 states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e. send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + + + +Loughney (editor) February 16, 2004 [Page 6] + + + + + +Internet-Draft + + + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are required + for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3 Path MTU Discovery & Packet Size + +4.3.1 Path MTU Discovery - RFC1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2 IPv6 Jumbograms - RFC2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + +4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5 Addressing + +4.5.1 IP Version 6 Addressing Architecture - RFC3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported. + +4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + + + +Loughney (editor) February 16, 2004 [Page 7] + + + + + +Internet-Draft + + + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4 Default Address Selection for IPv6 - RFC3484 + + The rules specified in the Default Address Selection for IPv6 [RFC- + 3484] document MUST be implemented. It is expected that IPv6 nodes + will need to deal with multiple addresses. + +4.5.5 Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- + 3315] is the standard stateful address configuration protocol; see + section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses aside from link-local addresses + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and which contains no prefixes advertised + for Stateless Address Autoconfiguration (see section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information such as the addresses of DNS servers when it is connected + to a link over which the node receives a router advertisement in + which the 'O' flag ("Other stateful configuration") is set. + +4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [MLDv2]. However, if the node has applications, which only need + support for Any- Source Multicast [RFC3569], the node MAY implement + MLDv1 [MLDv1] instead. If the node has applications, which need + support for Source- Specific Multicast [RFC3569, SSMARCH], the node + MUST support MLDv2 [MLDv2]. + + + + +Loughney (editor) February 16, 2004 [Page 8] + + + + + +Internet-Draft + + + When MLD is used, the rules in "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. Transport Layer and DNS + +5.1 Transport Layer + +5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 + + This specification MUST be supported if jumbograms are implemented + [RFC- 2675]. + +5.2 DNS + + DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] + and [RFC-3596] MAY be supported. Not all nodes will need to resolve + names. All nodes that need to resolve names SHOULD implement stub- + resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with + support for: + + - AAAA type Resource Records [RFC-3596]; + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extentions + [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 + + RFC 2732 MUST be supported if applications on the node use URL's. + +5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 + +5.3.1 Managed Address Configuration + + Those IPv6 Nodes that use DHCP for address assignment initiate DHCP + to obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set, as described + in section 5.5.3 of RFC 2462. In addition, in the absence of a + router, those IPv6 Nodes that use DHCP for address assignment MUST + initiate DHCP to obtain IPv6 addresses and other configuration + information, as described in section 5.5.2 of RFC 2462. Those IPv6 + nodes that do not use DHCP for address assignment can ignore the 'M' + + + +Loughney (editor) February 16, 2004 [Page 9] + + + + + +Internet-Draft + + + flag in Router Advertisements. + +5.3.2 Other Configuration Information + + Those IPv6 Nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to + obtain other configuration information. + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1 Transition Mechanisms + +6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 + + If an IPv6 node implements dual stack and tunneling, then RFC2893 + MUST be supported. + + RFC 2893 is currently being updated. + +7. Mobile IP + + The Mobile IPv6 [MIPv6] specification defines requirements for the + following types of nodes: + + - mobile nodes + - correspondent nodes with support for route optimization + - home agents + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [MIPv6], including support of generic packet tunneling [RFC-2473] + and secure home agent communications [MIPv6-HASEC]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [MIPv6]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY + support the home agent functionality described in Section 8.4 of + [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. + + + +Loughney (editor) February 16, 2004 [Page 10] + + + + + +Internet-Draft + + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1 Basic Architecture + + Security Architecture for the Internet Protocol [RFC-2401] MUST be + supported. RFC-2401 is being updated by the IPsec Working Group. + +8.2 Security Protocols + + ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. + RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. + + +8.3 Transforms and Algorithms + + Current IPsec RFCs specify the support of certain transforms and + algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. + The requirements for these are discussed first, and then additional + algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. + + NULL encryption algorithm [RFC-2410] MUST be supported for providing + integrity service and also for debugging use. + + The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD + NOT be supported. Security issues related to the use of DES are + discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as + required by the existing IPsec RFCs, but as it is currently viewed as + an inherently weak algorithm, and no longer fulfills its intended + role. + + The NULL authentication algorithm [RFC-2406] MUST be supported within + ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- + 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, + described in [RFC-2403] MUST be supported. An implementer MUST refer + to Keyed- Hashing for Message Authentication [RFC-2104]. + + 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC + and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- + CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected + to be a widely available, secure algorithm that is required for + interoperability. It is not required by the current IPsec RFCs, but + is expected to become required in the future. + + In addition to the above requirements, "Cryptographic Algorithm + Implementation Requirements For ESP And AH" [CRYPTREQ] contains the + current set of mandatory to implement algorithms for ESP and AH as + + + +Loughney (editor) February 16, 2004 [Page 11] + + + + + +Internet-Draft + + + well as specifying algorithms that should be implemented because they + may be promoted to mandatory at some future time. It is RECOMMENDED + that IPv6 nodes conform to the requirements in this document. + +8.4 Key Management Methods + + Manual keying MUST be supported. + + IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast + traffic. Where key refresh, anti-replay features of AH and ESP, or + on- demand creation of Security Associations (SAs) is required, + automated keying MUST be supported. Note that the IPsec WG is working + on the successor to IKE [IKE2]. Key management methods for multicast + traffic are also being worked on by the MSEC WG. + + "Cryptographic Algorithms for use in the Internet Key Exchange + Version 2" [IKEv2ALGO] defines the current set of mandatory to + implement algorithms for use of IKEv2 as well as specifying + algorithms that should be implemented because they made be promoted + to mandatory at some future time. It is RECOMMENDED that IPv6 nodes + implementing IKEv2 conform to the requirements in this + document. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1 General + +9.1.1 IPv6 Router Alert Option - RFC2711 + + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2 Neighbor Discovery for IPv6 - RFC2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + + + +Loughney (editor) February 16, 2004 [Page 12] + + + + + +Internet-Draft + + + nodes that are embedded devices, network management may be the only + possibility to control these nodes. + +10.1 Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + +10.1.1 IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes + that support an SNMP agent. + +10.1.2 Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an + SNMP agent. + +11. Security Considerations + + This draft does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC2460 describe the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + +12. References + +12.1 Normative + + [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- + tion Requirements For ESP And AH", draft-ietf-ipsec- + esp-ah-algorithms-01.txt, January 2004. + + [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the + Internet Key Exchange Version 2", draft-ietf-ipsec- + ikev2-algorithms-04.txt, Work in Progress. + + [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 + Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, + Work in Progress. + + [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support + in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 13] + + + + + +Internet-Draft + + + progress. + + [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec + to Protect Mobile IPv6 Signaling between Mobile Nodes + and Home Agents", draft-ietf- mobileip-mipv6-ha- + ipsec-06.txt, Work in Progress. + + [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version + 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in + Progress. + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table + MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in + Progress. + + [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the + Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- + update-07.txt, Work in progress. + + [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "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-2401] Kent, S. and Atkinson, R., "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication + Header", RFC 2402, November 1998. + + [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within + ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 + within ESP and AH", RFC 2404, November 1998. + + [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security + + + +Loughney (editor) February 16, 2004 [Page 14] + + + + + +Internet-Draft + + + Protocol (ESP)", RFC 2406, November 1998. + + [RFC-2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, + J., "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- + sion 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address + Autoconfiguration", RFC 2462. + + [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- + tocol Version 6 (IPv6)", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling + in IPv6 Specification", RFC 2473, December 1998. Xxx + add + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert + Option", RFC 2711, October 1999. + + + + +Loughney (editor) February 16, 2004 [Page 15] + + + + + +Internet-Draft + + + [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August + 2001. + + [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- + sion 6 (IPv6) Addresses in the Domain Name System + (DNS)", RFC 3363, August 2002. + + [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC + 3484, February 2003. + + [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the Multi- + cast Listener Discovery (MLD) Protocol", RFC 3590, + September 2003. + + [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP + version 6", RFC 3596, October 2003. + + [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use + with IPsec", RFC 3602, September 2003. + +12.2 Non-Normative + + [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", + draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in + Progress. + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, Jan + 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, Danvers, + MA, April 1995. + + [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- + vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 16] + + + + + +Internet-Draft + + + Progress. + + [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "DNS Security Introduction and Requirements" draft- + ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. + + [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- + gress. + + [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Protocol Modifications for the DNS Security Exten- + sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work + in Progress. + + [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- + col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", draft-savola-ipv6-rh-ha-security- + 03.txt, Work in Progress, March 2002. + + [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- + rity Threats and Counter-Measures; In Proceedings "Sympo- + sium on Network and Distributed System Security", Febru- + ary 1995, pp.2-16. + + [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, + August 1980. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- + ties", RFC 1034, November 1987. + + [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, + May 1997. + + [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and + S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC + 2205, September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2462, December 1998. + + [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over + ATM Networks", RFC 2492, January 1999. + + [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 + + + +Loughney (editor) February 16, 2004 [Page 17] + + + + + +Internet-Draft + + + Jumbograms", RFC 2675, August 1999. + + [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal + IPv6 Addresses in URL's", RFC 2732, December 1999. + + [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, + "Textual Conventions for Internet Network Addresses", RFC + 2851, June 2000. + + [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", + draft-ietf- ssm-arch-03.txt, Work in Progress. + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + + +Loughney (editor) February 16, 2004 [Page 18] + + + + + +Internet-Draft + + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- + penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, + Juha Ollila and Pekka Savola for their comments. + +14. Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + Email: John.Loughney@Nokia.com + +Notices + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to per- + tain to the implementation or use of the technology described in this + document or the extent to which any license under such rights might + or might not be available; neither does it represent that it has made + any effort to identify any such rights. Information on the IETF's + procedures with respect to rights in standards-track and standards- + related documentation can be found in BCP-11. Copies of claims of + rights made available for publication and any assurances of licenses + to be made available, or the result of an attempt made to obtain a + general license or permission for the use of such proprietary rights + by implementors or users of this specification can be obtained from + the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + + + +Loughney (editor) February 16, 2004 [Page 19] + + + + + +Internet-Draft + + + rights, which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 20] + + diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt new file mode 100644 index 0000000..a272d81 --- /dev/null +++ b/doc/draft/draft-ietf-secsh-dns-05.txt @@ -0,0 +1,614 @@ +Secure Shell Working Group J. Schlyter +Internet-Draft OpenSSH +Expires: March 5, 2004 W. Griffin + SPARTA + September 5, 2003 + + + Using DNS to Securely Publish SSH Key Fingerprints + draft-ietf-secsh-dns-05.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on March 5, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes a method to verify SSH host keys using + DNSSEC. The document defines a new DNS resource record that contains + a standard SSH key fingerprint. + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 1] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3 + 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3 + 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4 + 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4 + 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5 + 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5 + 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5 + 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 + Normative References . . . . . . . . . . . . . . . . . . . . 8 + Informational References . . . . . . . . . . . . . . . . . . 8 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + Intellectual Property and Copyright Statements . . . . . . . 10 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 2] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +1. Introduction + + The SSH [6] protocol provides secure remote login and other secure + network services over an insecure network. The security of the + connection relies on the server authenticating itself to the client + as well as the user authenticating itself to the server. + + If a connection is established to a server whose public key is not + already known to the client, a fingerprint of the key is presented to + the user for verification. If the user decides that the fingerprint + is correct and accepts the key, the key is saved locally and used for + verification for all following connections. While some + security-conscious users verify the fingerprint out-of-band before + accepting the key, many users blindly accept the presented key. + + The method described here can provide out-of-band verification by + looking up a fingerprint of the server public key in the DNS [1][2] + and using DNSSEC [5] to verify the lookup. + + In order to distribute the fingerprint using DNS, this document + defines a new DNS resource record, "SSHFP", to carry the fingerprint. + + Basic understanding of the DNS system [1][2] and the DNS security + extensions [5] is assumed by this document. + + 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 [3]. + +2. SSH Host Key Verification + +2.1 Method + + Upon connection to a SSH server, the SSH client MAY look up the SSHFP + resource record(s) for the host it is connecting to. If the + algorithm and fingerprint of the key received from the SSH server + match the algorithm and fingerprint of one of the SSHFP resource + record(s) returned from DNS, the client MAY accept the identity of + the server. + +2.2 Implementation Notes + + Client implementors SHOULD provide a configurable policy used to + select the order of methods used to verify a host key. This document + defines one method: Fingerprint storage in DNS. Another method + defined in the SSH Architecture [6] uses local files to store keys + for comparison. Other methods that could be defined in the future + might include storing fingerprints in LDAP or other databases. A + + + +Schlyter & Griffin Expires March 5, 2004 [Page 3] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + configurable policy will allow administrators to determine which + methods they want to use and in what order the methods should be + prioritized. This will allow administrators to determine how much + trust they want to place in the different methods. + + One specific scenario for having a configurable policy is where + clients do not use fully qualified host names to connect to servers. + In this scenario, the implementation SHOULD verify the host key + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + a DNS search path into the local resolver and forcing the client to + connect to a different host. + +2.3 Fingerprint Matching + + The public key and the SSHFP resource record are matched together by + comparing algorithm number and fingerprint. + + The public key algorithm and the SSHFP algorithm number MUST + match. + + A message digest of the public key, using the message digest + algorithm specified in the SSHFP fingerprint type, MUST match the + SSHFP fingerprint. + + +2.4 Authentication + + A public key verified using this method MUST NOT be trusted if the + SSHFP resource record (RR) used for verification was not + authenticated by a trusted SIG RR. + + Clients that do validate the DNSSEC signatures themselves SHOULD use + standard DNSSEC validation procedures. + + Clients that do not validate the DNSSEC signatures themselves MUST + use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8], + between themselves and the entity performing the signature + validation. + +3. The SSHFP Resource Record + + The SSHFP resource record (RR) is used to store a fingerprint of a + SSH public host key that is associated with a Domain Name System + (DNS) name. + + The RR type code for the SSHFP RR is TBA. + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 4] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +3.1 The SSHFP RDATA Format + + The RDATA for a SSHFP RR consists of an algorithm number, fingerprint + type and the fingerprint of the public host key. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | fp type | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / fingerprint / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 Algorithm Number Specification + + This algorithm number octet describes the algorithm of the public + key. The following values are assigned: + + Value Algorithm name + ----- -------------- + 0 reserved + 1 RSA + 2 DSS + + Reserving other types requires IETF consensus [4]. + +3.1.2 Fingerprint Type Specification + + The fingerprint type octet describes the message-digest algorithm + used to calculate the fingerprint of the public key. The following + values are assigned: + + Value Fingerprint type + ----- ---------------- + 0 reserved + 1 SHA-1 + + Reserving other types requires IETF consensus [4]. + + For interoperability reasons, as few fingerprint types as possible + should be reserved. The only reason to reserve additional types is + to increase security. + +3.1.3 Fingerprint + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 5] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + The fingerprint is calculated over the public key blob as described + in [7]. + + The message-digest algorithm is presumed to produce an opaque octet + string output which is placed as-is in the RDATA fingerprint field. + +3.2 Presentation Format of the SSHFP RR + + The RDATA of the presentation format of the SSHFP resource record + consists of two numbers (algorithm and fingerprint type) followed by + the fingerprint itself presented in hex, e.g: + + host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 + + The use of mnemonics instead of numbers is not allowed. + +4. Security Considerations + + Currently, the amount of trust a user can realistically place in a + server key is proportional to the amount of attention paid to + verifying that the public key presented actually corresponds to the + private key of the server. If a user accepts a key without verifying + the fingerprint with something learned through a secured channel, the + connection is vulnerable to a man-in-the-middle attack. + + The overall security of using SSHFP for SSH host key verification is + dependent on the security policies of the SSH host administrator and + DNS zone administrator (in transferring the fingerprint), detailed + aspects of how verification is done in the SSH implementation, and in + the client's diligence in accessing the DNS in a secure manner. + + One such aspect is in which order fingerprints are looked up (e.g. + first checking local file and then SSHFP). We note that in addition + to protecting the first-time transfer of host keys, SSHFP can + optionally be used for stronger host key protection. + + If SSHFP is checked first, new SSH host keys may be distributed by + replacing the corresponding SSHFP in DNS. + + If SSH host key verification can be configured to require SSHFP, + SSH host key revocation can be implemented by removing the + corresponding SSHFP from DNS. + + As stated in Section 2.2, we recommend that SSH implementors provide + a policy mechanism to control the order of methods used for host key + verification. One specific scenario for having a configurable policy + is where clients use unqualified host names to connect to servers. In + this case, we recommend that SSH implementations check the host key + + + +Schlyter & Griffin Expires March 5, 2004 [Page 6] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + against a local database before verifying the key via the fingerprint + returned from DNS. This would help prevent an attacker from injecting + a DNS search path into the local resolver and forcing the client to + connect to a different host. + + A different approach to solve the DNS search path issue would be for + clients to use a trusted DNS search path, i.e., one not acquired + through DHCP or other autoconfiguration mechanisms. Since there is no + way with current DNS lookup APIs to tell whether a search path is + from a trusted source, the entire client system would need to be + configured with this trusted DNS search path. + + Another dependency is on the implementation of DNSSEC itself. As + stated in Section 2.4, we mandate the use of secure methods for + lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This + is especially important if SSHFP is to be used as a basis for host + key rollover and/or revocation, as described above. + + Since DNSSEC only protects the integrity of the host key fingerprint + after it is signed by the DNS zone administrator, the fingerprint + must be transferred securely from the SSH host administrator to the + DNS zone administrator. This could be done manually between the + administrators or automatically using secure DNS dynamic update [11] + between the SSH server and the nameserver. We note that this is no + different from other key enrollment situations, e.g. a client sending + a certificate request to a certificate authority for signing. + +5. IANA Considerations + + IANA needs to allocate a RR type code for SSHFP from the standard RR + type space (type 44 requested). + + IANA needs to open a new registry for the SSHFP RR type for public + key algorithms. Defined types are: + + 0 is reserved + 1 is RSA + 2 is DSA + + Adding new reservations requires IETF consensus [4]. + + IANA needs to open a new registry for the SSHFP RR type for + fingerprint types. Defined types are: + + 0 is reserved + 1 is SHA-1 + + Adding new reservations requires IETF consensus [4]. + + + +Schlyter & Griffin Expires March 5, 2004 [Page 7] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Normative References + + [1] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [5] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. + Lehtinen, "SSH Protocol Architecture", + draft-ietf-secsh-architecture-14 (work in progress), July 2003. + + [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. + Lehtinen, "SSH Transport Layer Protocol", + draft-ietf-secsh-transport-16 (work in progress), July 2003. + +Informational References + + [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document + Roadmap", RFC 2411, November 1998. + + [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [10] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 8] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Authors' Addresses + + Jakob Schlyter + OpenSSH + 812 23rd Avenue SE + Calgary, Alberta T2G 1N8 + Canada + + EMail: jakob@openssh.com + URI: http://www.openssh.com/ + + + Wesley Griffin + SPARTA + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + + EMail: wgriffin@sparta.com + URI: http://www.sparta.com/ + +Appendix A. Acknowledgements + + The authors gratefully acknowledge, in no particular order, the + contributions of the following persons: + + Martin Fredriksson + + Olafur Gudmundsson + + Edward Lewis + + Bill Sommerfeld + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 9] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Schlyter & Griffin Expires March 5, 2004 [Page 10] + +Internet-Draft DNS and SSH Fingerprints September 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter & Griffin Expires March 5, 2004 [Page 11] + diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt new file mode 100644 index 0000000..3578d2a --- /dev/null +++ b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt @@ -0,0 +1,519 @@ + +Internet Draft Johan Ihren +draft-ihren-dnsext-threshold-validation-00.txt Autonomica +February 2003 +Expires in six months + + + Threshold Validation: + + A Mechanism for Improved Trust and Redundancy for DNSSEC Keys + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + +Abstract + + This memo documents a proposal for a different method of validation + for DNSSEC aware resolvers. The key change is that by changing from + a model of one Key Signing Key, KSK, at a time to multiple KSKs it + will be possible to increase the aggregated trust in the signed + keys by leveraging from the trust associated with the different + signees. + + By having multiple keys to chose from validating resolvers get the + opportunity to use local policy to reflect actual trust in + different keys. For instance, it is possible to trust a single, + particular key ultimately, while requiring multiple valid + signatures by less trusted keys for validation to succeed. + Furthermore, with multiple KSKs there are additional redundancy + benefits available since it is possible to roll over different KSKs + at different times which may make rollover scenarios easier to + manage. + +Contents + + 1. Terminology + 2. Introduction and Background + + 3. Trust in DNSSEC Keys + 3.1. Key Management, Split Keys and Trust Models + 3.2. Trust Expansion: Authentication versus Authorization + + 4. Proposed Semantics for Signing the KEY Resource Record + Set + 4.1. Packet Size Considerations + + 5. Proposed Use of Multiple "Trusted Keys" in a Validating + Resolver + 5.1. Not All Possible KSKs Need to Be Trusted + 5.2. Possible to do Threshold Validation + 5.3. Not All Trusted Keys Will Be Available + + 6. Additional Benefits from Having Multiple KSKs + 6.1. More Robust Key Rollovers + 6.2. Evaluation of Multiple Key Distribution Mechanisms + + 7. Security Considerations + 8. IANA Considerations. + 9. References + 9.1. Normative. + 9.2. Informative. + 10. Acknowledgments. + 11. Authors' Address + + +1. Terminology + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", + and "MAY" in this document are to be interpreted as described in + RFC 2119. + + The term "zone" refers to the unit of administrative control in the + Domain Name System. "Name server" denotes a DNS name server that is + authoritative (i.e. knows all there is to know) for a DNS zone, + typically the root zone. A "resolver", is a DNS "client", i.e. an + entity that sends DNS queries to authoritative nameservers and + interpret the results. A "validating resolver" is a resolver that + attempts to perform DNSSEC validation on data it retrieves by doing + DNS lookups. + + +2. Introduction and Background + + From a protocol perspective there is no real difference between + different keys in DNSSEC. They are all just keys. However, in + actual use there is lots of difference. First and foremost, most + DNSSEC keys have in-band verification. I.e. the keys are signed by + some other key, and this other key is in its turn also signed by + yet another key. This way a "chain of trust" is created. Such + chains have to end in what is referred to as a "trusted key" for + validation of DNS lookups to be possible. + + A "trusted key" is a the public part of a key that the resolver + acquired by some other means than by looking it up in DNS. The + trusted key has to be explicitly configured. + + A node in the DNS hierarchy that issues such out-of-band "trusted + keys" is called a "security apex" and the trusted key for that apex + is the ultimate source of trust for all DNS lookups within that + entire subtree. + + DNSSEC is designed to be able to work with more than on security + apex. These apexes will all share the problem of how to distribute + their "trusted keys" in a way that provides validating resolvers + confidence in the distributed keys. + + Maximizing that confidence is crucial to the usefulness of DNSSEC + and this document tries to address this issue. + + +3. Trust in DNSSEC Keys + + In the end the trust that a validating resolver will be able to put + in a key that it cannot validate within DNSSEC will have to be a + function of + + * trust in the key issuer, aka the KSK holder + + * trust in the distribution method + + * trust in extra, out-of-band verification + + The KSK holder needs to be trusted not to accidentally lose private + keys in public places. Furthermore it needs to be trusted to + perform correct identification of the ZSK holders in case they are + separate from the KSK holder itself. + + The distribution mechanism can be more or less tamper-proof. If the + key holder publishes the public key, or perhaps just a secure + fingerprint of the key in a major newspaper it may be rather + difficult to tamper with. A key acquired that way may be easier to + trust than if it had just been downloaded from a web page. + + Out-of-band verification can for instance be the key being signed + by a certificate issued by a known Certificate Authority that the + resolver has reason to trust. + +3.1. Simplicity vs Trust + + The fewer keys that are in use the simpler the key management + becomes. Therefore increasing the number of keys should only be + considered when the complexity is not the major concern. A perfect + example of this is the distinction between so called Key Signing + Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds + overall complexity but simplifies real life operations and was an + overall gain since operational simplification was considered to be + a more crucial issue than the added complexity. + + In the case of a security apex there are additional issues to + consider, among them + + * maximizing trust in the KSK received out-of-band + + * authenticating the legitimacy of the ZSKs used + + In some cases this will be easy, since the same entity will manage + both ZSKs and KSKs (i.e. it will authenticate itself, somewhat + similar to a self-signed certificate). In some environments it will + be possible to get the trusted key installed in the resolver end by + decree (this would seem to be a likely method within corporate and + government environments). + + In other cases, however, this will possibly not be sufficient. In + the case of the root zone this is obvious, but there may well be + other cases. + +3.2. Expanding the "Trust Base" + + For a security apex where the ZSKs and KSK are not held by the same + entity the KSK will effectively authenticate the identity of + whoever does real operational zone signing. The amount of trust + that the data signed by a ZSK will get is directly dependent on + whether the end resolver trusts the KSK or not, since the resolver + has no OOB access to the public part of the ZSKs (for practical + reasons). + + Since the KSK holder is distinct from the ZSK holder the obvious + question is whether it would then be possible to further improve + the situation by using multiple KSK holders and thereby expanding + the trust base to the union of that available to each individual + KSK holder. "Trust base" is an invented term intended to signify + the aggregate of Internet resolvers that will eventually choose to + trust a key issued by a particular KSK holder. + + A crucial issue when considering trust expansion through addition + of multiple KSK holders is that the KSK holders are only used to + authenticate the ZSKs used for signing the zone. I.e. the function + performed by the KSK is basically: + + "This is indeed the official ZSK holder for this zone, + I've verified this fact to the best of my abilitites." + + Which can be thought of as similar to the service of a public + notary. I.e. the point with adding more KSK holders is to improve + the public trust in data signed by the ZSK holders by improving the + strength of available authentication. + + Therefore adding more KSK holders, each with their own trust base, + is by definition a good thing. More authentication is not + controversial. On the contrary, when it comes to authentication, + the more the merrier. + + +4. Proposed Semantics for Signing the KEY Resource Record Set + + In DNSSEC according to RFC2535 all KEY Resource Records are used to + sign all authoritative data in the zone, including the KEY RRset + itself, since RFC2535 makes no distinction between Key Signing + Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS] + it is possible to change this to the KEY RRset being signed with + all KSKs and ZSKs but the rest of the zone only being signed by the + ZSKs. + + This proposal changes this one step further, by recommending that + the KEY RRset is only signed by the Key Signing Keys, KSK, and + explicitly not by the Zone Signing Keys, ZSK. The reason for this + is to maximize the amount of space in the DNS response packet that + is available for additional KSKs and signatures thereof. The rest + of the authoritative zone contents are as previously signed by only + the ZSKs. + +4.1. Packet Size Considerations + + The reason for the change is to keep down the size of the aggregate + of KEY RRset plus SIG(KEY) that resolvers will need to acquire to + perform validation of data below a security apex. For DNSSEC data + to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be + set, and therefore the allowed packet size can be assumed to be at + least the EDNS0 minimum of 4000 bytes. + + When querying for KEY + SIG(KEY) for "." (the case that is assumed + to be most crucial) the size of the response packet after the + change to only sign the KEY RR with the KSKs break down into a + rather large space of possibilities. Here are a few examples for + the possible alternatives for different numbers of KSKs and ZSKs + for some different key lengths (all RSA keys, with a public + exponent that is < 254). This is all based upon the size of the + response for the particular example of querying for + + ". KEY IN" + + with a response of entire KEY + SIG(KEY) with the authority and + additional sections empty: + + ZSK/768 and KSK/1024 (real small) + Max 12 KSK + 3 ZSK at 3975 + 10 KSK + 8 ZSK at 3934 + 8 KSK + 13 ZSK at 3893 + + ZSK/768 + KSK/1280 + MAX 10 KSK + 2 ZSK at 3913 + 8 KSK + 9 ZSK at 3970 + 6 KSK + 15 ZSK at 3914 + + ZSK/768 + KSK/1536 + MAX 8 KSK + 4 ZSK at 3917 + 7 KSK + 8 ZSK at 3938 + 6 KSK + 12 ZSK at 3959 + + ZSK/768 + KSK/2048 + MAX 6 KSK + 5 ZSK at 3936 + 5 KSK + 10 ZSK at 3942 + + ZSK/1024 + KSK/1024 + MAX 12 KSK + 2 ZSK at 3943 + 11 KSK + 4 ZSK at 3930 + 10 KSK + 6 ZSK at 3917 + 8 KSK + 10 ZSK at 3891 + + ZSK/1024 + KSK/1536 + MAX 8 KSK + 3 ZSK at 3900 + 7 KSK + 6 ZSK at 3904 + 6 KSK + 9 ZSK at 3908 + + ZSK/1024 + KSK/2048 + MAX 6 KSK + 4 ZSK at 3951 + 5 KSK + 8 ZSK at 3972 + 4 KSK + 12 ZSK at 3993 + + Note that these are just examples and this document is not making + any recommendations on suitable choices of either key lengths nor + number of different keys employed at a security apex. + + This document does however, based upon the above figures, make the + recommendation that at a security apex that expects to distribute + "trusted keys" the KEY RRset should only be signed with the KSKs + and not with the ZSKs to keep the size of the response packets + down. + + +5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver + + In DNSSEC according to RFC2535[RFC2535] validation is the process + of tracing a chain of signatures (and keys) upwards through the DNS + hierarchy until a "trusted key" is reached. If there is a known + trusted key present at a security apex above the starting point + validation becomes an exercise with a binary outcome: either the + validation succeeds or it fails. No intermediate states are + possible. + + With multiple "trusted keys" (i.e. the KEY RRset for the security + apex signed by multiple KSKs) this changes into a more complicated + space of alternatives. From the perspective of complexity that may + be regarded as a change for the worse. However, from a perspective + of maximizing available trust the multiple KSKs add value to the + system. + +5.1. Possible to do Threshold Validation + + With multiple KSKs a new option that opens for the security + concious resolver is to not trust a key individually. Instead the + resolver may decide to require the validated signatures to exceed a + threshold. For instance, given M trusted keys it is possible for + the resolver to require N-of-M signatures to treat the data as + validated. + + I.e. with the following pseudo-configuration in a validating + resolver + + security-apex "." IN { + keys { ksk-1 .... ; + ksk-2 .... ; + ksk-3 .... ; + ksk-4 .... ; + ksk-5 .... ; + }; + validation { + # Note that ksk-4 is not present below + keys { ksk-1; ksk-2; ksk-3; ksk-5; }; + # 3 signatures needed with 4 possible keys, aka 75% + needed-signatures 3; + }; + }; + + we configure five trusted keys for the root zone, but require two + valid signatures for the top-most KEY for validation to + succeed. I.e. threshold validation does not force multiple + signatures on the entire signature chain, only on the top-most + signature, closest to the security apex for which the resolver has + trusted keys. + +5.2. Not All Trusted Keys Will Be Available + + With multiple KSKs held and managed by separate entities the end + resolvers will not always manage to get access to all possible + trusted keys. In the case of just a single KSK this would be fatal + to validation and necessary to avoid at whatever cost. But with + several fully trusted keys available the resolver can decide to + trust several of them individually. An example based upon more + pseudo-configuration: + + security-apex "." IN { + keys { ksk-1 .... ; + ksk-2 .... ; + ksk-3 .... ; + ksk-4 .... ; + ksk-5 .... ; + }; + validation { + # Only these two keys are trusted independently + keys { ksk-1; ksk-4; }; + # With these keys a single signature is sufficient + needed-signatures 1; + }; + }; + + Here we have the same five keys and instruct the validating + resolver to fully trust data that ends up with just one signature + from by a fully trusted key. + + The typical case where this will be useful is for the case where + there is a risk of the resolver not catching a rollover event by + one of the KSKs. By doing rollovers of different KSKs with + different schedules it is possible for a resolver to "survive" + missing a rollover without validation breaking. This improves + overall robustness from a management point of view. + +5.3. Not All Possible KSKs Need to Be Trusted + + With just one key available it simply has to be trusted, since that + is the only option available. With multiple KSKs the validating + resolver immediately get the option of implementing a local policy + of only trusting some of the possible keys. + + This local policy can be implemented either by simply not + configuring keys that are not trusted or, possibly, configure them + but specify to the resolver that certain keys are not to be + ultimately trusted alone. + + +6. Additional Benefits from Having Multiple KSKs + +6.1. More Robust Key Rollovers + + With only one KSK the rollover operation will be a delicate + operation since the new trusted key needs to reach every validating + resolver before the old key is retired. For this reason it is + expected that long periods of overlap will be needed. + + With multiple KSKs this changes into a system where different + "series" of KSKs can have different rollover schedules, thereby + changing from one "big" rollover to several "smaller" rollovers. + + If the resolver trusts several of the available keys individually + then even a failure to track a certain rollover operation within + the overlap period will not be fatal to validation since the other + available trusted keys will be sufficient. + +6.2. Evaluation of Multiple Key Distribution Mechanisms + + Distribution of the trusted keys for the DNS root zone is + recognized to be a difficult problem that ... + + With only one trusted key, from one single "source" to distribute + it will be difficult to evaluate what distribution mechanism works + best. With multiple KSKs, held by separate entitites it will be + possible to measure how large fraction of the resolver population + that is trusting what subsets of KSKs. + + +7. Security Considerations + + From a systems perspective the simplest design is arguably the + best, i.e. one single holder of both KSK and ZSKs. However, if that + is not possible in all cases a more complex scheme is needed where + additional trust is injected by using multiple KSK holders, each + contributing trust, then there are only two alternatives + available. The first is so called "split keys", where a single key + is split up among KSK holders, each contributing trust. The second + is the multiple KSK design outlined in this proposal. + + Both these alternatives provide for threshold mechanisms. However + split keys makes the threshold integral to the key generating + mechanism (i.e. it will be a property of the keys how many + signatures are needed). In the case of multiple KSKs the threshold + validation is not a property of the keys but rather local policy in + the validating resolver. A benefit from this is that it is possible + for different resolvers to use different trust policies. Some may + configure threshold validation requiring multiple signatures and + specific keys (optimizing for security) while others may choose to + accept a single signature from a larger set of keys (optimizing for + redundancy). Since the security requirements are different it would + seem to be a good idea to make this choice local policy rather than + global policy. + + Furthermore, a clear issue for validating resolvers will be how to + ensure that they track all rollover events for keys they + trust. Even with operlap during the rollover (which is clearly + needed) there is still a need to be exceedingly careful not to miss + any rollovers (or fail to acquire a new key) since without this + single key validation will fail. With multiple KSKs this operation + becomes more robust, since different KSKs may roll at different + times according to different rollover schedules and losing one key, + for whatever reason, will not be crucial unless the resolver + intentionally chooses to be completely dependent on that exact key. + +8. IANA Considerations. + + NONE. + + +9. References + +9.1. Normative. + + [RFC2535] Domain Name System Security Extensions. D. Eastlake. + March 1999. + + [RFC3090] DNS Security Extension Clarification on Zone Status. + E. Lewis. March 2001. + + +9.2. Informative. + + [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System + (DNS). D. Eastlake 3rd. May 2001. + + [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. + December 2001. + + [DS] Delegation Signer Resource Record. + O. Gudmundsson. October 2002. Work In Progress. + +10. Acknowledgments. + + Bill Manning came up with the original idea of moving complexity + from the signing side down to the resolver in the form of threshold + validation. I've also had much appreciated help from (in no + particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and + Olaf Kolkman. + + +11. Authors' Address +Johan Ihren +Autonomica AB +Bellmansgatan 30 +SE-118 47 Stockholm, Sweden +johani@autonomica.se diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt new file mode 100644 index 0000000..d857cd9 --- /dev/null +++ b/doc/draft/draft-kato-dnsop-local-zones-00.txt @@ -0,0 +1,295 @@ + + + +Internet Engineering Task Force Akira Kato, WIDE +INTERNET-DRAFT Paul Vixie, ISC +Expires: August 24, 2003 February 24, 2003 + + + Operational Guidelines for "local" zones in the DNS + draft-kato-dnsop-local-zones-00.txt + +Status of this Memo + + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as ``work in progress.'' + +To view the list Internet-Draft Shadow Directories, see +http://www.ietf.org/shadow.html. + +Distribution of this memo is unlimited. + +The internet-draft will expire in 6 months. The date of expiration will +be August 24, 2003. + + +Abstract + +A large number of DNS queries regarding to the "local" zones are sent +over the Internet in every second. This memo describes operational +guidelines to reduce the unnecessary DNS traffic as well as the load of +the Root DNS Servers. + +1. Introduction + +While it has yet been described in a RFC, .local is used to provide a +local subspace of the DNS tree. Formal delegation process has not been +completed for this TLD. In spite of this informal status, .local has +been used in many installations regardless of the awareness of the +users. Usually, the local DNS servers are not authoritative to the +.local domain, they end up to send queries to the Root DNS Servers. + +There are several other DNS zones which describe the "local" +information. .localhost has been used to describe the localhost for +more than a couple of decades and virtually all of the DNS servers are +configured authoritative for .localhost and its reverse zone .127.in- + + +KATO Expires: August 24, 2003 [Page 1] + + +DRAFT DNS local zones February 2003 + +addr.arpa. However, there are other "local" zones currently used in the +Internet or Intranets connected to the Internet through NATs or similar +devices. + +At a DNS server of an university in Japan, half of the DNS queries sent +to one of the 13 Root DNS Servers were regarding to the .local. At +another DNS Server running in one of the Major ISPs in Japan, the 1/4 +were .local. If those "local" queries are able to direct other DNS +servers than Root, or they can be resolved locally, it contributes the +reduction of the Root DNS Servers. + +2. Rationale + +Any DNS queries regarding to "local" names should not be sent to the DNS +servers on the Internet. + +3. Operational Guidelines + +Those queries should be processed at the DNS servers internal to each +site so that the severs respond with NXDOMAIN rather than sending +queries to the DNS servers outside. + +The "local" names have common DNS suffixes which are listed below: + +3.1. Local host related zones: + +Following two zones are described in [Barr, 1996] and .localhost is also +defined in [Eastlake, 1999] . + + o .localhost + o .127.in-addr.arpa + + +Following two zones are for the loopback address in IPv6 [Hinden, 1998] +. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush, +2001] , the old TLD .int has been used for this purpose for years +[Thomson, 1995] and many implementations still use .int. So it is +suggested that both zones should be provided for each IPv6 reverse +lookup zone for a while. + + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int + o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa + + +3.2. Locally created name space + +While the use of .local has been proposed in several Internet-Drafts, it +has not been described in any Internet documents with formal status. +However, the amount of the queries for .local is much larger than +others, it is suggested to resolve the following zone locally: + + + + +KATO Expires: August 24, 2003 [Page 2] + + +DRAFT DNS local zones February 2003 + + o .local + + + +3.3. Private or site-local addresses + +The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site- +local addresses [Hinden, 1998] should be resolved locally: + + o 10.in-addr.arpa + o 16.172.in-addr.arpa + o 17.172.in-addr.arpa + o 18.172.in-addr.arpa + o 19.172.in-addr.arpa + o 20.172.in-addr.arpa + o 21.172.in-addr.arpa + o 22.172.in-addr.arpa + o 23.172.in-addr.arpa + o 24.172.in-addr.arpa + o 25.172.in-addr.arpa + o 26.172.in-addr.arpa + o 27.172.in-addr.arpa + o 28.172.in-addr.arpa + o 29.172.in-addr.arpa + o 30.172.in-addr.arpa + o 31.172.in-addr.arpa + o 168.192.in-addr.arpa + o c.e.f.ip6.int + o d.e.f.ip6.int + o e.e.f.ip6.int + o f.e.f.ip6.int + o c.e.f.ip6.arpa + o d.e.f.ip6.arpa + o e.e.f.ip6.arpa + o f.e.f.ip6.arpa + + +3.4. Link-local addresses + +The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden, +1998] should be resolved locally: + + o 254.169.in-addr.arpa + o 8.e.f.ip6.int + o 9.e.f.ip6.int + o a.e.f.ip6.int + o b.e.f.ip6.int + o 8.e.f.ip6.arpa + o 9.e.f.ip6.arpa + o a.e.f.ip6.arpa + o b.e.f.ip6.arpa + + + +KATO Expires: August 24, 2003 [Page 3] + + +DRAFT DNS local zones February 2003 + +4. Suggestions to developers + +4.1. Suggestions to DNS software implementors + +In order to avoid unnecessary traffic, it is suggested that DNS software +implementors provide configuration templates or default configurations +so that the names described in the previous section are resolved locally +rather than sent to other DNS servers in the Internet. + +4.2. Suggestions to developers of NATs or similar devices + +There are many NAT or similar devices available in the market. +Regardless of the availability of DNS Servers in those devices, it is +suggested that those devices are able to filter the DNS traffic or +respond to the DNS traffic related to "local" zones by configuration +regardless of its ability of DNS service. It is suggested that this +functionality is activated by default. + +5. IANA Consideration + +While .local TLD has yet defined officially, there are substantial +queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the +traffic sent to the Root DNS Servers are related to the .local zone. +Therefore, while it is not formally defined, it is suggested that IANA +delegates .local TLD to an organization. + +The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918 +address and the link-local address. It has several DNS server instances +around the world by using BGP Anycast [Hardie, 2002] . So the AS112 +Project is one of the candidates to host the .local TLD. + +Authors' addresses + + Akira Kato + The University of Tokyo, Information Technology Center + 2-11-16 Yayoi Bunkyo + Tokyo 113-8658, JAPAN + Tel: +81 3-5841-2750 + Email: kato@wide.ad.jp + + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063, USA + Tel: +1 650-779-7001 + Email: vixie@isc.org + + + + + + + +KATO Expires: August 24, 2003 [Page 4] + + +DRAFT DNS local zones February 2003 + +References + +To be filled + +References + +Barr, 1996. +D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912 +(February 1996). + +Eastlake, 1999. +D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999). + +Hinden, 1998. +R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in +RFC2373 (July 1998). + +Bush, 2001. +R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001). + +Thomson, 1995. +S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in +RFC1886 (December 1995). + +Rekhter, 1996. +Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, +"Address Allocation for Private Internets" in RFC1918 (February 1996). + +IANA, 2002. +IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002). + +Vixie, . +P. Vixie, "AS112 Project" in AS112. http://www.as112.net/. + +Hardie, 2002. +T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast +Addresses" in RFC3258 (April 2002). + + + + + + + + + + + + + + + + + +KATO Expires: August 24, 2003 [Page 5] + diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt new file mode 100644 index 0000000..f9eaf26 --- /dev/null +++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt @@ -0,0 +1,1830 @@ + + + + INTERNET-DRAFT S. Daniel Park + Expires: October 2003 Syam Madanapalli + File: SAMSUNG Electronics + draft-park-ipv6-extensions-dns-pnp-00.txt April 2003 + + + + + IPv6 Extensions for DNS Plug and Play + + + + Status of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet-Drafts + as reference material or to cite them other than as "work in + progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + + Abstract + + This document proposes automatic configuration of domain name (FQDN) + for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as + a part of IPv6 plug and play feature. 6DNAC allows the automatic + registration of domain name and corresponding IPv6 Addresses with + the DNS server. In order to provide 6DNAC function, Neighbor Discovery + Protocol [2461] will be used. Moreover, 6DNAC does not require any + changes to the existing DNS system. + + + Table of Contents + + 1. Introduction ............................................. 3 + 2. Terminology .............................................. 3 + 3. 6DNAC Design Principles .................................. 4 + 4. 6DNAC Overview ........................................... 4 + 5. 6DNAC Requirements ....................................... 5 + 5.1. 6DANR Client Requirements ................................ 5 + 5.2. 6DNAC Server Requirements ................................ 6 + +Park & Madanapalli Expires October 2003 [Page 1] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 6. 6DNAC Messages and Option Formats ........................ 6 + 6.1. Router Advertisement (RA) Message Format ................. 6 + 6.2. Neighbor Solicitation (NS) Message Format ................ 7 + 6.3. Neighbor Advertisement (NA) Message Format ............... 8 + 6.4. Option Formats ........................................... 8 + 6.4.1. DNS Zone Suffix Information Option Format ................ 8 + 6.4.2. Domain Name (FQDN) Option Format ......................... 9 + 6.4.3. Router Alert Option for 6DNAC ............................ 10 + 7. 6DNAC Operation .......................................... 10 + 7.1. 6DNAC Network Topology ................................... 11 + 7.2. 6DNAC Operational Scenarios .............................. 12 + 7.2.1. Domain Name Registration-Success Case .................... 12 + 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14 + 7.2.3. Domain Name Registration-Defend Case ..................... 16 + 7.2.4. Domain Name Registration in Retry Mode ................... 19 + 7.2.5. Domain Name Registration when DAD Fails .................. 20 + 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22 + 7.3.1. Sending Router Advertisement Messages .................... 22 + 7.3.2. Processing Router Advertisement Messages ................. 22 + 7.3.3. FQDN Lifetime expiry ..................................... 23 + 7.3.4. Host Naming Algorithm .................................... 23 + 7.4. Duplicate Domain Name Detection .......................... 23 + 7.4.1. DAD with All Nodes Multicast Address ..................... 24 + 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24 + 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24 + 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25 + 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25 + 7.4.1.5. Pros and Cons ............................................ 25 + 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25 + 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25 + 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26 + 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26 + 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26 + 7.4.2.5. Pros and Cons ............................................ 26 + 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26 + 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26 + 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26 + 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27 + 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27 + 7.4.3.5. Pros and Cons ............................................ 27 + 7.4.4. Retry Mode for Re-registering Domain Name ................ 27 + 7.5. Domain Name Registration ................................. 27 + 8. Security Consideration ................................... 27 + 9. IANA Consideration ....................................... 28 + 10. Acknowledgement .......................................... 28 + 11. Intellectual Property .................................... 28 + 12. Copyright ................................................ 28 + 13. References ............................................... 29 + 14. Author's Addresses ....................................... 30 + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 2] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 1. Introduction + + Today, most networks use DNS[1034][1035] for convenience. In case of + IPv6, DNS is more important element because of IPv6 long addresses + which are difficult to remember. In addition, small networks like home + networks using IPv6, should be able to make network easily without + manual configuration. Also, these small networks may not have DHCP + Server, DNS Server etc. that are used to configure the network. This + document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure + for generating and registering the Domain Name and IPv6 addresses with + the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are + required to implement lightweight functions specified in this document. + 6DNAC can be applied to all defined IPv6 unicast addresses except Link + local IPv6 addresses, viz: Site-local and Global addresses. + + 6DNAC uses Neighbor Discovery Protocol [2461] with new additions + (defined in section 6) and DAD procedures for generating and + registering the Domain Name with the DNS server automatically. + + + 2. Terminology + + 6DNAC - IPv6 Domain Name Auto Configuration. It can provide + IPv6 hosts with Domain Name Generation and + Registration automatically. + + 6DNAC Client - An IPv6 node that can generate its own unique Domain + Name. Section 3 identifies the new requirements that + 6DNAC places on an IPv6 node to be a 6DNAC node. + + 6DNAC Server - An IPv6 node that can collect and registrate Domain + Name and IPv6 addresses automatically. 6DNAC server + uses the information from the DAD operation messages + with newly defined options for the registration of the + Domain Name and IPv6 Addresses. Section 3 identifies + the new requirements that 6DNAC places on an IPv6 + node to be a 6DNAC server. Also 6DNAC server can have + various other functions depending on network + environment and the network operator. For instance + 6DNAC Server can acts as a Gateway as well Home Server + in Home Networks. + + DAD - Duplicate Address Detection (is defined [2461]) + + DFQDND - Duplicate Domain Name Detection + + FQDN - Fully Qualified Domain Name - FQDN and Domain Name are + used interchangeably in this document. + + NA - Neighbor Advertisement message (is defined [2461]) + + NS - Neighbor Solicitation message (is defined [2461]) + + RA - Router Advertisement message (is defined [2461]) + + SLAAC - Stateless Address Autoconfiguration [2462]. + +Park & Madanapalli Expires October 2003 [Page 3] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 3. 6DNAC Design Principles + + This section discusses the design principles of 6DNAC mechanism. + + 1. The new procedures for plug and play DNS should not cause changes + to existing DNS system. 6DNAC requires lightweight functions to be + implemented only at the client side of the DNS system, and uses the + existing DDNS UPDATE [2136] to communicate with DNS Servers. + + 2. Introducing a new protocol will always introduce new problems. + 6DNAC uses the existing protocols NDP [2461] with minor extensions + for generating and registering the domain name automatically + without defining a new protocol + + 3. Reusing proven and well understood design principles/patterns + will always yield a robust system. 6DNAC is based on IPv6 Address + Auotoconfiguration principle, where routers advertise the prefix + and host adds the interface ID to the prefix and forms the IPv6 + address. Domain Name (FQDN) also contains two parts: host name + and DNS zone suffix. Routers can advertise the DNS zone suffix + on a particular link in Router Advertisements (RA Messages) and + hosts can prefix their preferred host name to the DNS zone suffix + and form the fully qualified domain name. Also the detection of + duplicate domain name is similar to Duplicate Address Detection + (DAD) and can be part of DAD operation itself. + + + 4. 6DNAC Overview + + 6DNAC proposes minor extensions to NDP [2461] for automatic generation + and registration of domain name with the DNS server. It introduces two + new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone + Suffix option is carried in Router Advertisement (RA) messages for + notifying IPv6 nodes about the valid DNS Zone Suffix on the link and + FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement + (NA) messages to detect duplicate domain name. 6DNAC consists of two + components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the + domain name based on DNS Zone Suffix using Host Naming Algorithm (see + section 7.3.1) and 6DNAC Server collects and registers the DNS + information with the DNS Server on behalf of 6DNAC Clients. + + The automatic configuration of domain name using 6DNAC consists of + three parts. + + - DNS Zone Suffix Discovery and FQDN Construction: + + IPv6 Nodes collect DNS Zone Suffix information from Router + Advertisements and constructs FQDN by prefixing host name to the + DNS Zone Suffix. The IPv6 Nodes are required to implement Host + Naming Algorithm for generating host part of the FQDN in the + absence of administrator. + + Generation of node's FQDN within the node itself has advantages. Nodes + can provide forward and reverse name lookups independent of the DNS + System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain + Name is some thing that is owned by the node. + +Park & Madanapalli Expires October 2003 [Page 4] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + - Duplicate Domain Name Detection + + All nodes are expected to go for DAD for all new IPv6 unicast + addresses, regardless of whether they are obtained through + stateful, stateless or manual configuration. 6DNAC uses the DAD + messages with new option for carrying the Domain Name along with + the new IPv6 Address. 6DNAC Server captures this information and + updates DNS Server provided that the IPv6 Address and its domain + name are not duplicate. If the domain name is already in use, + the 6DNAC server replies to the sender with FQDN Option in NA + message indicating that the domain name is duplicate. Then the + node is expected to generate another domain name using host + naming algorithm and go for DAD. This time the DAD is only for + duplicate domain name detection (DFQDND). In order to avoid + confusion with the normal NDP processing, the target address + field of the NS message must carry the unspecified address + in retry mode. This can be repeated depending on number of + retries defined by the administrator in the host naming algorithm. + + + - Domain Name Registration + + 6DNAC Server detects the DNS information (IPv6 Address and + corresponding FQDN) from DAD/DFQDND messages and updates DNS + Server using existing protocol DDNS UPDATE [2136] provided that + the IPv6 Address and its domain name are not duplicate. + + If an IPv6 Address is duplicate, the IPv6 node cannot perform + stateless address autoconfiguration repeatedly. Unlike IPv6 stateless + address autoconfiguration, 6DNAC allows the automatic configuration of + domain name repeatedly if the domain name is duplicate depending on + number of retries defined by the administrator in the host naming + algorithm. + + + 5. 6DNAC Requirements + + Depending on the 6DNAC functionality, the IPv6 nodes implement, they + are called either 6DNAC Clients or 6DNAC Servers. The following + sections lists the requirements that the 6DNAC Client and 6DNAC server + must support. + + + 5.1. 6DANC Client Requirements + + - 6DNAC Client must recognize and process the following NDP + extensions + + - DNS Zone Suffix option in RA messages for generating its + domain name (FQDN). + + - Domain Name option in NS and NA messages for detecting + the duplicate domain name + + + + +Park & Madanapalli Expires October 2003 [Page 5] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + - It must generate its domain name (FQDN) based on the DNS + suffix that it got from the router advertisement. And it must + have a host naming algorithm for generating the host part of + the FQDN. + + - If NA message is received with unspecified target address and + FQDN option, then the node must treat that the domain is + duplicate. + + + 5.2. 6DNAC Server Requirements + + - 6DNAC Server must recognize and process the following NDP + extensions + + - If the 6DNAC Server is a router on the link, then it + must advertise DNS Zone Suffix option in RA messages + for hosts to generate their domain name (FQDN). + + - FQDN option in NS messages for detecting new DNS + information for of nodes on the link for which it + must update the AAAA RR and PTR RR in DNS Server. + + - FQDN option in NA messages for notifying duplicate + domain name with unspecified target address. + + - 6DNAC server must update the DNS Server (both AAAA RR and + PTR RR) dynamically using DDNS UPDATE [2136]. + + - 6DNAC server must cache this (newly detected) FQDN, Link + Layer Address, and IPv6 Address information, so that it can + decide whether it really needs to update DNS Server or not, + to avoid redundant updates. This information will also be + used for notifying the duplicate domain name. + + + 6. 6DNAC Messages and Option Formats + + In order to achieve the plug and play DNS, 6DNAC proposes new + extensions to the NDP [2461]. This section specifies the new + additions to NDP messages and formats of new options. + + + 6.1. Router Advertisement (RA) Message Format + + Routers send out Router Advertisement (RA) message periodically, or + in response to a Router Solicitation. 6DNAC does not modify the format + of the RA message, but proposes new option (DNS Zone Suffix Information) + to be carried in RA messages. + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 6] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cur Hop Limit |M|O| Reserved | Router Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reachable Time | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retrans Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | DNS Zone Suffix Information | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + <Figure: 1 RA message> + + + + 6.2. Neighbor Solicitation (NS) Message Format + + 6DNAC does not modify the format of the Neighbor Solicitation (NS) + message, but proposes new option (FQDN Option) to be carried in NS + messages. When a node is going for DAD, the node must include FQDN + option in NS message to participate in plug and play DNS. If the + node is going for Explicit Detection of Duplicate Domain Name, the + node must use FQDN option in NS message and unspecified address in + the target address field. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | Domain Name | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + <Figure: 2 NS message> + +Park & Madanapalli Expires October 2003 [Page 7] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 6.3. Neighbor Advertisement (NA) Message Format + + 6DNAC does not modify the format of the Neighbor Advertisement (NA) + message, but proposes new option (FQDN Option) to be carried in NA + messages. 6DNAC Server sends NA message with FQDN option to 6DNAC + Client that is performing duplicate domain name detection in case + the domain name found to be duplicate. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|S|O| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... | + / / + | FQDN Option | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + <Figure: 3 NA message> + + + 6.4 Option Formats + + 6.4.1. DNS Zone Suffix Information Option Format + + IPv6 nodes require DNS Zone Suffix for constructing their FQDN. + 6DNAC introduces new option for routers to advertise the DNS Zone + Suffix Information for IPv6 nodes on the link. The suffix information + should be configured into routers manually. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / DNS Zone Suffix / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + <Figure: 4 DNS Zone Suffix Information> + +Park & Madanapalli Expires October 2003 [Page 8] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + Type [TBD] + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units of + 8 octets. + + Reserved This field is unused. It must be initialized to zero + by the sender and must be ignored by the receiver. + + Valid Life Time 32-bit signed integer. The maximum time, in + seconds, over which this suffix is valid. Nodes + should treat this as the life time for their domain + name. Nodes should contact the source of this + information before expiry of this time interval. + A value of all one bits (0xFFFFFFFF) represents + infinity. + + DNS Zone Suffix The suffix part of the FQDN. The data in the DNS + Zone Suffix field should be encoded according to + DNS encoding rules specified in [1035]. + + + + 6.4.2. Domain Name (FQDN) Option Format + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + FQDN Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / Domain Name / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + <Figure: 5 FQDN Information> + + Type [TBD] + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units + of 8 octets. It must be greater than 3. + + + +Park & Madanapalli Expires October 2003 [Page 9] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + Reserved This field is unused. It must be initialized to + zero by the sender and must be ignored by the + receiver. + + Valid Life Time 32-bit signed integer. The maximum time, in + seconds, over which this domain name is valid + 6DNAC should deregister this domain name at + the expiry of this interval. 6DNAC clients + should send updates by the expiry of this + interval. A value of all one bits (0xFFFFFFFF) + represents infinity. + + FQDN Target Address The Address for which the FQDN maps to. It + should be same as Target Address field of the + NS message in case of DAD & duplicate FQDN are + running in parallel. + + Domain Name The domain name (FQDN) of the node. The data in + the domain name should be encoded according to + DNS encoding rules specified in [1035]. + + + 6.4.3. Router Alert Option for 6DNAC + + Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop + Header for using in NDP messages. The presence of this option in NS + message informs the router that this NS message is carrying Domain + Name information and must be processed by the 6DNAC Server on the router. + 6DNAC Clients can use this option for sending DAD packets instead + of addressing the DAD packets to the all-nodes multicast address + when 6DNAC Server is implemented on router. + + The Router Alert option has the following format: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Length = 2 + + Values are registered and maintained by the IANA. For 6DNAC, the + value has to be assigned by IANA. + + Further information about this option can be obtained from + IPv6 Router Alert Option [2711]. + + + 7. 6DNAC Operation + + 6DNAC provides mechanisms for automatic generation of domain name + and registering it with the DNS Server for IPv6 nodes. 6DNAC consists + of two components: 6DNAC Client and 6DNAC Server. All nodes that want + to participate in plug and play DNS are required to implement 6DNAC + Client functionality, and one of the IPv6 nodes is required to + implement 6DNAC Server functionality. The IPv6 node that implements + the 6DNAC Server functionality must know the location of the DNS + Server and must be a trusted node to send DDNS UPDATE [2136] messages. + +Park & Madanapalli Expires October 2003 [Page 10] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 7.1. 6DNAC Network Topology + + This section identifies the possible locations for the 6DNAC Server. + Note that, all nodes are required to implement 6DNAC Client + functionality for constructing the domain name from the DNS Zone + Suffix Information advertised by the router. Figure 6 illustrates + IPv6 host (H4) implementing 6DNAC Server functionality. In this case + H4 can serve only one link (that it belongs to) for automatic + registration of domain name. H4 must observe the DAD packets on the + link to detect the DNS information, this requires all nodes on the + link must belong to same solicited node multicast address. In general, + this may not be the case. So the node that is going for DAD must use + all nodes multicast address for DAD packets, so that the 6DNAC Server + (H4) can observe the DAD packets, detects IPv6 address and + corresponding domain name, checks if this domain name is duplicate + and finally registers the domain name with the DNS Server. + + + 6DNAC Server + +---+ +---+ +----------+ + | H1| | H4|<--- DDNS UPDATE --->|DNS Server| + +-+-+ +-+-+ +----+-----+ + | | +----+ +---/ + | | | | / + ---+-----+-----------+-----+-----------+ R1 +-----+ + | | | | + | | +----+ + +-+-+ +-+-+ + | H2| | H3| + +---+ +---+ + + + H1, H2, H3 - 6DNAC Clients + H4 - 6DNAC Server + R1 - Router + + + <Figure: 6 Example of 6DNAC Topology> + + + Figure 7 shows the 6DNAC Server implemented on a router R1. In this + case a single 6DNAC server can serve multiple links for automatic + configuration of the domain name. This topology also has flexibility + of using DAD packets with Router Alert option instead of sending DAD + packets to all nodes multicast address. The routers are required to + process all the packets with Router Alert option as per [2711]. + + In case of Home Networks, R1 is will acts as a Home Gateway (CPE) + connected to ISP. R1 delegates the prefix from the ISP edge router. + After delegating the prefix the CPE can advertise the DNS Zone suffix + along with the prefix information to the nodes on the links to which + the router is connected to. Note that the R1 must be configured with + the DNS Zone suffix Information manually. + + + + +Park & Madanapalli Expires October 2003 [Page 11] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---+ +---+ + | H3+ | H4| + +-+-+ +-+-+ + | | + | LINK2 | + +---+ ---+--------+--+-- +----------+ + | H1| | |DNS Server| + +-+-+ | +----+-----+ + | +--+-+ -------/ + | LINK 1 | | / + ---+-----+------------------+ R1 +---------+ + | | | DDNS UPDATE + | +----+ + +-+-+ 6DNAC Server + | H2| + +---+ + + + H1, H2 - 6DNAC Clients on Link1 + H3, H4 - 6DNAC Clients on Link2 + R1 - Router with 6DNAC Server, serving both Link1 and Link2 + + + <Figure: 7 Example of 6DNAC Server serving multiple links> + + + 7.2. 6DNAC Operational Scenarios + + This section provides message sequence charts for various 6DNAC + operational scenarios assuming that the 6DNAC Server is implemented + on a router. All the scenarios assume that the normal boot up time + stateless address autoconfiguration of Link Local address derived + from the Interface Identifier has been completed successfully. And + it is also assumed that the router is already configured with the + DNS Zone Suffix Information. + + + Legend: + + 6DNAC-A, B, C : 6DNAC Clients + 6DNAC-S : 6DNAC Server/Router + DAD : Duplicate Address Detection + DFQDND : Duplicate Domain Name Detection + DNS-S : DNS Server + + + 7.2.1. Domain Name Registration-Successful Case + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. It is Assumed that the + DupAddrDetectTransmits is set to 1. + + + + +Park & Madanapalli Expires October 2003 [Page 12] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + | RA with | | + | DNS Suffix Opt | | + |<---------------| | + | #1 | | + |---+ | | + Construct |#2 | | + FQDN | | | + |<--+ | | +DAD/DFQDND Starts | | + | | | + | | | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #3 | | + | | | + | |------+ | + | Create FQDN | #4 | + | <FQDN,C> | | + | |<-----+ | + | | | + | | Register FQDN | + | |--------------->| + | | #5 | + | #6 | | + |--------+ | | + No Response | | | + DFQDND-Success | | | + |<-------+ | | + | | | + | | | + v V v + + + <Figure: 8 Domain Name Generation and Registration> + + + #1. 6DNAC Server (Router) sends out router advertisement with DNS + Suffix information along with other parameters as specified in + NDP [2461]. + + #2. 6DNAC Client processes the router advertisement and constructs + the FQDN by prefixing hostname to the DNS Zone Suffix. It also + constructs IPv6 address from the autoconfiguration prefix + information option. + + #3. 6DNAC Client starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor + Solicitation message with FQDN option. + + Note that the DAD packets must be addressed to all nodes multicast + address if Router Alert option is not used. + +Park & Madanapalli Expires October 2003 [Page 13] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #4. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client as part of duplicate FQDN detection procedure and + creates a FQDN entry in its FQDN Cache (assuming that there is no + entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client. + + #5. 6DNAC Server then registers FQDN and corresponding IPv6 address + through the existing protocol DDNS UPDATE. + + #6. 6DNAC Client times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name. + + Note that, Stateless Address Autoconfiguration DAD procedure is not + depicted in the following message sequence chart, which simultaneously + happens along with duplicate FQDN detection. + + + 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. The node is configured with + DupAddrDetectTransmits = 2 for reliability in delivering DAD messages. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 14] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + | RA with | | + | DNS Suffix Opt | | + |<---------------| | + | #1 | | + |---+ | | + Construct |#2 | | + FQDN | | | + |<--+ | | +DAD/DFQDND Starts | | + | | | + | | | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #3 | | + | | | + | |------+ | + | Create FQDN | #4 | + | <FQDN,C> | | + | |<-----+ | + | | | + | | Register FQDN | + | |--------------->| + | | #5 | + | NS With | | + | FQDN Opt | | + |--------------->| | + | #6 | | + | | | + | Lookup FQDN | + | Entry exists | + | |------+ | + | Ignore | #7 | + | |<-----+ | + | #8 | | + |--------+ | | + No Response | | | + DFQDND-Success | | | + |<-------+ | | + | | | + | | | + v V v + + + + <Figure: 9 Verification of duplicated Domain Name> + + + Steps from #1 to #5 are same as that of scenario.7.2.1. + + #6. 6DNAC Client sends out second Neighbor Solicitation message with + FQDN option as part of duplicate FQDN detection. + +Park & Madanapalli Expires October 2003 [Page 15] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #7. 6DNAC Server receives and observes that the FQDN Cache exactly + matches with that of the NS information and ignores the NS message. + + #8. 6DNAC Client times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name.. + + + 7.2.3. Domain Name Registration-Defend Case + + This scenario starts when two 6DNAC Client receive RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and both the nodes want configure their IPv6 + address (Global or Site Local) and domain name. In this scenario both + the nodes want to have same domain name. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 16] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + + +---------+ +---------+ +---------+ +---------+ + | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | RA with | RA with | | + | DNS Suffix Opt | DNS Suffix Opt | | + |<---------------|--------------->| | + | #1 | #1 | | + |---+ | |---+ | + Construct | #2 | Construct | #2 | + FQDN | | FQDN | | + |<--+ | |<--+ | + DAD/DFQDND Starts | DAD/DFQDND Starts | + | | <DELAYED> | + | | | | + | NS with | | | + | FQDN Opt | | | + |--------------->| | | + | #3 | | | + | No Entry | | + | |------+ | | + | Create FQDN | #4 | | + | <FQDN,A> | | | + | |<-----+ | | + | | | | + | | Register FQDN #5 | + | |-------------------------------->| + | | | | + | | NS with | | + | | FQDN Opt | | + | |<---------------| | + | | #6 | | + | |------+ | | + | FQDN is in use| | | + | Defend DFQDND| #7 | | + | |<-----+ | | + | | | | + | | NA with | | + | | D-flag Set | | + | |--------------->| | + | | #8 | | + |------+ | |---+ | + No Response | #9 | Enter | #10 | + DFQDND Success| | Retry Mode| | + |<-----+ | |<--+ | + | | | | + v v v v + + + <Figure: 10 Multiple Hosts Requesting Same Domain Name> + + + + + +Park & Madanapalli Expires October 2003 [Page 17] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #1. 6DNAC Server (Router) sends out router advertisement with DNS + Suffix information. + + #2. 6DNAC Clients A&B process the router advertisement and construct + their FQDN by prefixing hostname to the DNS Zone Suffix. They + also construct IPv6 address from the autoconfiguration prefix + information option. + + When each host is trying to go for DAD, all hosts must have + random delay to avoid the traffic congestion according to [2461]. + So here it is assumed that 6DNAC Client-A starts DAD first and + 6DNAC Client-B starts DAD later. + + #3. 6DNAC Client-A starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor + Solicitation message with FQDN option. + + #4. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client-A as part of duplicate FQDN detection procedure and + creates a FQDN entry in its FQDN Cache (assuming that there is no + entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A. + + #5. 6DNAC Server then registers FQDN and corresponding IPv6 address + through the existing protocol DDNS UPDATE. + + #6. 6DNAC Client-B starts duplicate address & FQDN detection for the + IPv6 address & FQDN constructed and sends out a Neighbor Solicitation + message with FQDN option. + + #7. 6DNAC Server processes the Neighbor Solicitation message sent by + 6DNAC Client-B as part of duplicate FQDN detection procedure and + finds that the domain name is already in use by the 6DNAC Client-A. + Hence, concludes to defend the duplicate FQDN detection of 6DNAC + Client-B. + + #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN + option to 6DNAC Client-B to defend its duplicate FQDN detection. + + #9. 6DNAC Client-A times out and observes that there is no response to + defend its duplicate FQDN detection procedure and the node is + successful in configuring its domain name. + + #10. 6DNAC Client-B observes that there is a NA with FQDN option + indicating that the domain name is duplicate and enters Retry + Mode. In retry mode, 6DNAC Client constructs another FQDN based + on Host Naming Algorithm. The number of retries is defined by the + administrator and must be a configurable value. + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 18] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + 7.2.4. Domain Name Registration in Retry Mode + + Pre-Conditions: + + 1. Duplicate Address Detection has succeeded + 2. Duplicate FQDN Detection FAILED + 3. FQDN is the first FQDN one constructed and FAILED + 4. FQDN2 is the second FQDN to be constructed + 5. The Neighbor Solicitation in the 'Retry Mode' + carries unspecified address in its target field (NS*). + + +---------+ +---------+ +---------+ + | 6DNAC-C | | 6DNAC-S | | DNS-S | + +----+----+ +----+----+ +----+----+ + | | | + |--------+ | | + Construct | #1 | | + new FQDN2 | | | + |<-------+ | | + | | | + DFQDND Restarts | | + | | | + | | | + | NS* With | | + | FQDN Opt | | + |--------------->| | + | #2 | | + | | | + | No Entry | + | |------+ | + | Create FQDN | #3 | + | <FQDN2,C> | | + | |<-----+ | + | | | + | | Register FQDN2 | + | |--------------->| + | | #4 | + | | | + |--------+ | | + No Response | #5 | | + DFQDND-Success | | | + |<-------+ | | + | | | + v V v + + + <Figure: 11 Regeneration of Domain Name> + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 19] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm, + the DNS Zone Suffix, and it is FQDN2. + #2. It then starts Duplicate Detection only for Domain Name. 6DNAC + Client sends out NS with FQDN option and unspecified target + address. + + #3. 6DNAC Server processes the Retry Mode NS message and finds that + the FQDN2 is not in use and creates Cache entry as <FQDN2, C>. + + #4. It then starts registration procedures with the DNS Server. + + #5. Meanwhile, 6DNAC Client timesout and observes that there is no + defending NA for its DFQDND NS sent out and successfully + configures its domain name. + + + 7.2.5. Domain Name Registration when DAD Fails + + Duplicate domain name detection and subsequent registration starts + if and only if the DAD for IPv6 address succeeds. If the DAD for + IPv6 address fails then no actions are taken for domain name. When + DAD fails for stateless address autoconfiguration, then the domain + configuration starts only when the address has been configured using + Stateful Address Configuration methods and the node is going on DAD + for this address. + + This scenario starts when a 6DNAC Client receives RA message with + DNS Zone Suffix and other parameters including address prefix as + specified in NDP [2461] and wants configure its IPv6 address (Global + or Site Local) and domain name. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 20] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + +---------+ +---------+ +---------+ +---------+ + | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | | | | + | RA with | | | + | DNS Suffix Opt | | | + |<---------------| | | + | #1 | | | + |-----+ | | | + Construct | | | | + FQDN& | #2 | | | + IPv6 Addr | | | | + |<----+ | | | + DAD/DFQDND Starts | | | + | | | | + | | | | + | NS with | | | + | FQDN Opt | | | + |--------------->+--------------->| | + | #3 | #3 | | + | No Entry | | + | |------+ | | + | Create FQDN | | | + | <FQDN,A> | #4 | | + | |<-----+ | | + | | | | + | | |------+ | + | | My IPv6 Addr| #5 | + | | |<-----+ | + | | Defend DAD | | + | | with NA | | + |<---------------+<---------------| | + | #6 | #6 | | + | Entry | | + | |------+ | | + | Delete FQDN | #7 | | + | |<-----+ | | + | | | | + |----+ | | | + DAD Failed | #8 | | | + Stop DFQDND | | | | + |<---+ | | | + | | | | + v v v v + + <Figure: 12 DAD failure> + + #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A. + + #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and + FQDN as per Host Naming Algorithm. + + #3. It then starts Duplicate address & FQDN Detection, for the newly + constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS + with FQDN option. + +Park & Madanapalli Expires October 2003 [Page 21] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + #4. 6DNAC Server processes the DAD/DFQDND NS message and finds + that there is no entry for the FQDN in its cache. And, + creates Cache entry as <FQDN, A> and starts a Registration + timer with RegistrationWaitTime seconds. + + #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is + in its unicast address list. + + #6. It then starts defending DAD by sending NA to all-nodes multicast. + + #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A. + And, deletes its FQDN Cache entry <FQDN,A>. + + #8. 6DNAC Client gets defending DAD-NA and desists from DAD. + And also, stops Duplicate FQDN Detection as well. + At this point the address must be configured using stateful + methods and the domain name registration starts with the DAD + for the newly constructed IPv6 address. + + 7.3. DNS Zone Suffix Discovery and FQDN Construction + + 7.3.1. Sending Router Advertisement Messages + + Routers send out Router Advertisement message periodically, + or in response to a Router Solicitation. Router should include + the DNS Zone Suffix Option in their advertisements. If the DNS + Zone Suffix changes (similar to Site Renumbering), then it should + advertise the Old Zone Suffix with zero Valid Lifetime and New + Zone Suffix with proper non-zero Valid Lifetime. In any other + case, a router should not send this option twice in a single + router advertisement. + + 7.3.2. Processing Router Advertisement Messages + + For each DNS Zone Suffix Option in Router Advertisement, + + a. 6DNAC node stores the Zone Suffix information in its local + database. Also, constructs FQDN as per Host Naming Algorithm. + + b. If the node has not configured FQDN yet, + + 1. If the node is going to perform DAD for either Site local or + Global Address, then it should include FQDN option to perform + Duplicate FQDN Detection in parallel with DAD. + + 2. If the node has already got either Site local or Global + address, then it should send out NS with FQDN option and + unspecified target address to perform Duplicate FQDN + Detection. + + c. If the node has already configured FQDN, and if the + advertisement carries two DNS Zone Suffix Options, + First DNS Zone Suffix should match with the configured FQDN + Suffix and its Valid Lifetime must be zero. Second DNS Zone + + + +Park & Madanapalli Expires October 2003 [Page 22] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + Suffix should have non-zero Valid Lifetime. In this case, the + node constructs new FQDN based on the new DNS Zone Suffix (from + second DNS Zone Suffix option), and perform Duplicate FQDN + Detection with unspecified target address. Also, it should + overwrite the old FQDN with the newly constructed FQDN. + + + 7.3.3. FQDN Lifetime expiry + + 6DNAC Server: + It should delete the FQDN cache entry and should de-register from + the DNS Server. + + 6DNAC Client: + It should send update to 6DNAC Server by restarting the Duplicate + FQDN Detection. + + 7.3.4. Host Naming Algorithm + + A node constructs FQDN by combining DNS Zone Suffix and the hostname + as depicted in the following diagram. + + +------------------+----------------------------------+ + | Host Name | Advertised Suffix | + +------------------+----------------------------------+ + + <Figure 13: Fully Qualified Domain Name format> + + A node can choose Host Name using any of the following methods: + + a. String form of random number generated from the Interface + Identifier. + + b. List of configured Host Names provided by the administrator. + + + The number of retries must be specified in this algorithm in + case of domain name duplication. + + + 7.4. Duplicate Domain Name Detection + + The procedure for detecting duplicated FQDNs uses Neighbor + Solicitation and Advertisement messages as described below. + + If a duplicate FQDN is detected during the procedure, the + FQDN cannot be assigned to the node. + + An FQDN on which the DFQDND Procedure is applied is said + to be tentative until the procedure has completed successfully. + A tentative FQDN is not considered "assigned to the node" in the + traditional sense. That is, the node must accept Neighbor + Advertisement message containing the tentative FQDN in the FQDN + Option. + + +Park & Madanapalli Expires October 2003 [Page 23] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + It should also be noted that DFQDN must be performed prior to + registering with DNS Server to prevent multiple nodes from using + the same FQDN simultaneously. All the Duplicate Address Detection + Neighbor Solicitation messages must carry Source Link Layer Address + Option as specified in NDP [2461]. + + The detection of duplicate FQDN can be achieved through one of the + following three types of procedures. + + 1. DAD with All Nodes Multicast Address + 2. DAD with Router Alert Option for 6DNAC. + 3. Explicit Detection of Duplicate Domain Name + + Even though three solutions are listed, authors prefer only one + procedure to be followed in future based on further analysis and + comments received from others. + + 7.4.1. DAD with All Nodes Multicast Address + + 7.4.1.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate Address Detection SLAAC [2462] with the following + extra information and modifications: + + a. Include FQDN Option in the DAD Neighbor Solicitation Message + b. Destination Address is set to All Nodes Multicast Address + + There may be a case where DAD has succeeded but DFQDND is in Retry + Mode. In such case, the Neighbor Solicitation must carry unspecified + address in the ICMP target address field and new domain name in FQDN + option to re-try the registration of the domain name. + + 7.4.1.2. Processing Neighbor Solicitation Messages + + 6DNAC Clients must ignore the FQDN option found in any of the + neighbor solicitation messages. + + 6DNAC Server processes FQDN Option found in the Duplicate Address + Detection Neighbor Solicitation Messages as described below: + + Lookup FQDN Cache for the domain name in FQDN Option. + + If the entry exists and + i. Link Layer Address matches with SLLA option, this is the case, + where node has changed its IPv6 address or updating the valid + life time. 6DNAC Server updates its cache and also updates DNS + Server using DDNS-UPDATE. If there is no change in IPv6 address + or life time then no updates are sent to the DNS server. + + ii. Link Layer Address differs with SLLA option, defend the duplicate + FQDN Detection by sending Neighbor Advertisement Message as + described in $7.4.1.3$. + + + +Park & Madanapalli Expires October 2003 [Page 24] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + else, + Lookup FQDN Cache for the Link Layer Address in SLLA Option. + + If the entry exists, update the FQDN Cache and update DNS Server + using DDNS-UPDATE. This is the case, where node has changed its + domain name (similar to Site Re-numbering). + + If then entry does not exists, then it means that this is the new + registration. It must create a cache entry and start Registration + + timer with RegistrationWaitTime. At the expiry of the Registration + timer, it should update DNS Server with DDNS-UPDATE. + + 7.4.1.3. Sending Neighbor Advertisement Messages + + 6DNAC Server sends Neighbor Advertisement Messages as part + of Duplicate Address Detection SLAAC [2462] with the FQDN Option + in Neighbor Advertisement message to defend duplicate FQDN + detection. + + There may be the case where defending of duplicate address detection + is not required but defending of FQDN is required. In such instance, + the defending Neighbor Advertisement must carry FQDN and unspecified + address in the ICMP target address field. + + 7.4.1.4. Processing Neighbor Advertisement Messages + + 6DNAC Server must ignore the any FQDN option found any of + the neighbor advertisement messages. If the Neighbor Advertisement + is a DAD defending, then it must delete its FQDN Cache entry created + on the reception of DAD Neighbor Solicitation message. + + When 6DNAC Clients gets the duplicate address detection neighbor + advertisement messages with FQDN option set it means that its + duplicate FQDN detection failed and enters Retry Mode. + + 7.4.1.5. Pros and Cons + + The advantage of this procedure is that it does not need any + extension header options to be included. The disadvantage of this + procedure is that, it needs change in the existing DAD procedure. + The change is only that the DAD neighbor solicitations are to be + addressed to all nodes multicast address instead of solicited + node multicast address. The another disadvantage is that, it needs + the existence of Duplicate Address Detection Procedure to + perform duplicate FQDN detection. + + 7.4.2. DAD with Router Alert Option for 6DNAC + + 7.4.2.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate Address Detection SLAAC [2462] with the following + extra information: + + +Park & Madanapalli Expires October 2003 [Page 25] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + a. Include Hop-by-Hop extension Header with Router Alert Option + for 6DNAC as described in IPv6 Router Alert Option[2711]. + + b. Include FQDN Option in the DAD Neighbor Solicitation Message + + 7.4.2.2. Processing Neighbor Solicitation Messages + + This is same as described in $7.4.1.2$. + + 7.4.2.3. Sending Neighbor Advertisement Messages + + This is same as described in $7.4.1.3$. + + 7.4.2.4. Processing Neighbor Advertisement Messages + + This is same as described in $7.4.1.4$. + + 7.4.2.5. Pros and Cons + + The advantage of this procedure is that it does not disturb + the existing implementation and their way of processing the + packets. The disadvantage is that, it needs the existence + of Duplicate Address Detection Procedure to perform duplicate + FQDN detection. Another disadvantage is that this procedure + requires 6DNAC Server functionality to be implemented on Router. + However, in this case 6DNAC Server can serve multiple links. + + 7.4.3. Explicit Detection of Duplicate Domain Name + + In this procedure Duplicate FQDN Detection starts after completion + of successful Site local or Global Address configuration. + + 7.4.3.1. Sending Neighbor Solicitation Messages + + 6DNAC Client sends Neighbor Solicitation Messages as part + of Duplicate FQDN Detection with the following information: + + a. Include FQDN Option in the Neighbor Solicitation Message + + b. Destination Address is set to All Nodes Multicast Address + or uses Router Alert Option for 6DNAC, when 6DNAC Server is + implemented on router. + + c. Target Address is set to Unspecified Address + + d. Other fields are set as per DAD SLAAC [2462]. + + 7.4.3.2. Processing Neighbor Solicitation Messages + + This is same as described in $7.4.1.2$. + + + + + + +Park & Madanapalli Expires October 2003 [Page 26] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + 7.4.3.3. Sending Neighbor Advertisement Messages + + This is same as described in $7.4.1.3$. + + 7.4.3.4. Processing Neighbor Advertisement Messages + + This is same as described in $7.4.1.4$. + + 7.4.3.5. Pros and Cons + + The advantage of this procedure is that it does not need the + existing duplicate address detection procedure. This is introduced + as the DAD procedure is found to be redundant in when IPv6 addresses + are constructed from the interface ID [DIID]. + + Note that, if 6DNAC Clients know the address of 6DNAC Server then + they can directly send DFQDND-NS to 6DNAC Server. + + 7.4.4. Retry Mode for Re-registering Domain Name + + In retry mode, nodes construct new FQDN as per Host Naming Algorithm. + Then they restart Duplicate FQDN Detection as described in $7.4.3$. + + + 7.5. Domain Name Registration + + 6DNAC Server must be an authenticated to update the DNS Server. + 6DNAC Server must also be configured with the DNS Server + information. + + 6DNAC Server detects the DNS information (IPv6 Address and + corresponding FQDN) from DAD/DFQDND messages and caches the + information. It also have an associated Registration Timer with + RegistrationWaitTime to wait for the successful completion of + DFQDND and update DNS Server using existing protocol DDNS UPDATE + [2136]. + + + 8. Security Consideration + + If someone wants to hijack correct Domain Name registration, they + could send a NS message with incorrect or same Domain Name to the + 6DNAC server repeatedly and server would start the Domain Name + registration through above mechanism, which is a security hole. + As described in [2461], a host can check validity of NDP messages. + If the NDP message include an IP Authentication Header, the message + authenticates correctly. For DNS UPDATE processing, secure DNS + Dynamic Update is described in [3007]. + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 27] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + 9. IANA Consideration + + Values in the Router Alert Option are registered and maintained by + IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is + required to assign the Type values for DNS Zone Suffix Information + option and FADN option. + + + 10. Acknowledgement + + Special thanks are due to Badrinarayana N.S. and Christian Huitema for + many helpful suggestions and revisions. + + + 11. Intellectual Property + + The following notice is copied from RFC 2026 [Bradner, 1996], + Section 10.4, and describes the position of the IETF concerning + intellectual property claims made against this document. + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use other technology described in + + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances + of licenses to be made available, or the result of an attempt made + to obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification + can be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + 12. Copyright + + The following copyright notice is copied from RFC 2026 [Bradner, + 1996], Section 10.4, and describes the applicable copyright for this + document. + + Copyright (C) The Internet Society July 12, 2001. All Rights + Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + +Park & Madanapalli Expires October 2003 [Page 28] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + 13. References + + [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [2460] Deering, S. abd R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor + Discovery for IP version 6(IPv6)", RFC 2461, December + 1998. + + [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto- + Configuration", RFC 2462, December 1998. + + [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option", + RFC 2711, October 1999. + + [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND + FACILITIES", RFC 1034, November 1987. + + [1035] P. Mockapetris, "Domain Names - Implementation and + Specification" RFC 1035, November 1987. + + [2136] P. Vixie et al., "Dynamic Updates in the Domain Name + System (DNS UPDATE)", RFC2136, April 1997. + + [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + + +Park & Madanapalli Expires October 2003 [Page 29] + +INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003 + + + [DIID] yokohama-dad-vs-diid.pdf + at http://playground.sun.com/ipng/presentations/July2002/ + + [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf- + dnsop-ipv6-dns-issues-00.txt, work in progress. + + [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix + delegation", draft-ietf-ipv6-prefix-delegation- + requirement-01.txt, work in progress. + + [Autoreg] H. Kitamura, "Domain Name Auto-Registration for + Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name- + auto-reg-00.txt, work in progress. + + [NIQ] Matt Crawford, "IPv6 Node Information Queries", <draft- + ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress. + + + 14. Author's Addresses + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics, KOREA + Phone: +82-31-200-3728 + Email:soohong.park@samsung.com + + Syam Madanapalli + Network Systems Division, SAMSUNG India Software Operations, INDIA + Phone: +91-80-5550555 + Email:syam@samsung.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Park & Madanapalli Expires October 2003 [Page 30] diff --git a/doc/draft/update b/doc/draft/update new file mode 100644 index 0000000..6ac2090 --- /dev/null +++ b/doc/draft/update @@ -0,0 +1,46 @@ +#!/bin/sh +commit= +for i +do + z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'` + if test -n "$z" + then + i="$z" + fi + if test -f "$i" + then + continue + fi + pat=`echo "$i" | sed 's/...txt/??.txt/'` + old=`echo $pat 2> /dev/null` + if test "X$old" != "X$pat" + then + newer=0 + for j in $old + do + if test $j ">" $i + then + newer=1 + fi + done + if test $newer = 1 + then + continue; + fi + fi + if fetch "http://www.ietf.org/internet-drafts/$i" + then + cvs add "$i" + if test "X$old" != "X$pat" + then + rm $old + cvs delete $old + commit="$commit $old" + fi + commit="$commit $i" + fi +done +if test -n "$commit" +then + cvs commit -m "new draft" $commit +fi |