diff options
Diffstat (limited to 'contrib/bind9/doc/draft')
48 files changed, 0 insertions, 42044 deletions
diff --git a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt deleted file mode 100644 index 1030e57..0000000 --- a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - - -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/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt b/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt deleted file mode 100644 index fffa8a5..0000000 --- a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - -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/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt deleted file mode 100644 index 4a01d91..0000000 --- a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt +++ /dev/null @@ -1,1960 +0,0 @@ - - - -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/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt b/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt deleted file mode 100644 index 7b5e8cc..0000000 --- a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt +++ /dev/null @@ -1,241 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt deleted file mode 100644 index 224e7ad1..0000000 --- a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt +++ /dev/null @@ -1,240 +0,0 @@ -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/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt deleted file mode 100644 index fa41e76..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt +++ /dev/null @@ -1,928 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt deleted file mode 100644 index f0ce70a..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt +++ /dev/null @@ -1,393 +0,0 @@ - - - -INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc. - November 2002 - - - DNS Zone Transfer Protocol Clarifications - - -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 - - In the Domain Name System, zone data is replicated among - authoritative DNS servers by means of the "zone transfer" protocol, - also known as the "AXFR" protocol. This memo clarifies, updates, and - adds missing detail to the original AXFR protocol specification in - RFC1034. - -1. Introduction - - The original definition of the DNS zone transfer protocol consists of - a single paragraph in [RFC1034] section 4.3.5 and some additional - notes in [RFC1035] section 6.3. It is not sufficiently detailed to - serve as the sole basis for constructing interoperable - implementations. This document is an attempt to provide a more - complete definition of the protocol. Where the text in RFC1034 - conflicts with existing practice, the existing practice has been - codified in the interest of interoperability. - - - - -Expires May 2003 [Page 1] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - 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. The zone transfer request - - To initiate a zone transfer, the slave server sends a zone transfer - request to the master server over a reliable transport such as TCP. - The form of this request is specified in sufficient detail in RFC1034 - and needs no further clarification. - - Implementers are advised that one server implementation in widespread - use sends AXFR requests where the TCP message envelope size exceeds - the DNS request message size by two octets. - -3. The zone transfer response - - If the master server is unable or unwilling to provide a zone - transfer, it MUST respond with a single DNS message containing an - appropriate RCODE other than NOERROR. If the master is not - authoritative for the requested zone, the RCODE SHOULD be 9 - (NOTAUTH). - - Slave servers should note that some master server implementations - will simply close the connection when denying the slave access to the - zone. Therefore, slaves MAY interpret an immediate graceful close of - the TCP connection as equivalent to a "Refused" response (RCODE 5). - - If a zone transfer can be provided, the master server sends one or - more DNS messages containing the zone data as described below. - -3.1. Multiple answers per message - - The zone data in a zone transfer response is a sequence of answer - RRs. These RRs are transmitted in the answer section(s) of one or - more DNS response messages. - - The AXFR protocol definition in RFC1034 does not make a clear - distinction between response messages and answer RRs. Historically, - DNS servers always transmitted a single answer RR per message. This - encoding is wasteful due to the overhead of repeatedly sending DNS - message headers and the loss of domain name compression - opportunities. To improve efficiency, some newer servers support a - mode where multiple RRs are transmitted in a single DNS response - message. - - A master MAY transmit multiple answer RRs per response message up to - the largest number that will fit within the 65535 byte limit on TCP - - - -Expires May 2003 [Page 2] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - DNS message size. In the case of a small zone, this can cause the - entire transfer to be transmitted in a single response message. - - Slaves MUST accept messages containing any number of answer RRs. For - compatibility with old slaves, masters that support sending multiple - answers per message SHOULD be configurable to revert to the - historical mode of one answer per message, and the configuration - SHOULD be settable on a per-slave basis. - -3.2. DNS message header contents - - RFC1034 does not specify the contents of the DNS message header of - the zone transfer response messages. The header of each message MUST - be as follows: - - ID Copy from request - QR 1 - OPCODE QUERY - AA 1, but MAY be 0 when RCODE is not NOERROR - TC 0 - RD Copy from request, or 0 - RA Set according to availability of recursion, or 0 - Z 0 - AD 0 - CD 0 - RCODE NOERROR on success, error code otherwise - - The slave MUST check the RCODE in each message and abort the transfer - if it is not NOERROR. It SHOULD check the ID of the first message - received and abort the transfer if it does not match the ID of the - request. The ID SHOULD be ignored in subsequent messages, and fields - other than RCODE and ID SHOULD be ignored in all messages, to ensure - interoperability with certain older implementations which transmit - incorrect or arbitrary values in these fields. - -3.3. Additional section and SIG processing - - Zone transfer responses are not subject to any kind of additional - section processing or automatic inclusion of SIG records. SIG RRs in - the zone data are treated exactly the same as any other RR type. - -3.4. The question section - - RFC1034 does not specify whether zone transfer response messages have - a question section or not. The initial message of a zone transfer - response SHOULD have a question section identical to that in the - request. Subsequent messages SHOULD NOT have a question section, - though the final message MAY. The receiving slave server MUST accept - - - -Expires May 2003 [Page 3] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - any combination of messages with and without a question section. - -3.5. The authority section - - The master server MUST transmit messages with an empty authority - section. Slaves MUST ignore any authority section contents they may - receive from masters that do not comply with this requirement. - -3.6. The additional section - - The additional section MAY contain additional RRs such as transaction - signatures. The slave MUST ignore any unexpected RRs in the - additional section. It MUST NOT treat additional section RRs as zone - data. - -4. Zone data - - The purpose of the zone transfer mechanism is to exactly replicate at - each slave the set of RRs associated with a particular zone at its - primary master. An RR is associated with a zone by being loaded from - the master file of that zone at the primary master server, or by some - other, equivalent method for configuring zone data. - - This replication shall be complete and unaltered, regardless of how - many and which intermediate masters/slaves are involved, and - regardless of what other zones those intermediate masters/slaves do - or do not serve, and regardless of what data may be cached in - resolvers associated with the intermediate masters/slaves. - - Therefore, in a zone transfer the master MUST send exactly those - records that are associated with the zone, whether or not their owner - names would be considered to be "in" the zone for purposes of - resolution, and whether or not they would be eligible for use as glue - in responses. The transfer MUST NOT include any RRs that are not - associated with the zone, such as RRs associated with zones other - than the one being transferred or present in the cache of the local - resolver, even if their owner names are in the zone being transferred - or are pointed to by NS records in the zone being transferred. - - The slave MUST associate the RRs received in a zone transfer with the - specific zone being transferred, and maintain that association for - purposes of acting as a master in outgoing transfers. - -5. Transmission order - - RFC1034 states that "The first and last messages must contain the - data for the top authoritative node of the zone". This is not - consistent with existing practice. All known master implementations - - - -Expires May 2003 [Page 4] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - send, and slave implementations expect to receive, the zone's SOA RR - as the first and last record of the transfer. - - Therefore, the quoted sentence is hereby superseded by the sentence - "The first and last RR transmitted must be the SOA record of the - zone". - - The initial and final SOA record MUST be identical, with the possible - exception of case and compression. In particular, they MUST have the - same serial number. The slave MUST consider the transfer to be - complete when, and only when, it has received the message containing - the second SOA record. - - The transmission order of all other RRs in the zone is undefined. - Each of them SHOULD be transmitted only once, and slaves MUST ignore - any duplicate RRs received. - -6. Security Considerations - - The zone transfer protocol as defined in [RFC1034] and clarified by - this memo does not have any built-in mechanisms for the slave to - securely verify the identity of the master server and the integrity - of the transferred zone data. The use of a cryptographic mechanism - for ensuring authenticity and integrity, such as TSIG [RFC2845], - IPSEC, or TLS, is RECOMMENDED. - - The zone transfer protocol allows read-only public access to the - complete zone data. Since data in the DNS is public by definition, - this is generally acceptable. Sites that wish to avoid disclosing - their full zone data MAY restrict zone transfer access to authorized - slaves. - - These clarifications are not believed to themselves introduce any new - security problems, nor to solve any existing ones. - -Acknowledgements - - 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. - -References - - [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, - November 1987. - - - - -Expires May 2003 [Page 5] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - [RFC1035] - Domain Names - Implementation and Specifications, P. - Mockapetris, November 1987. - - [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels, - S. Bradner, BCP 14, March 1997. - - [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P. - Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000. - -Author's Address - - Andreas Gustafsson - Nominum Inc. - 2385 Bay Rd - Redwood City, CA 94063 - USA - - Phone: +1 650 381 6004 - - Email: gson@nominum.com - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000 - 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 implmentation 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 - - - -Expires May 2003 [Page 6] - -draft-ietf-dnsext-axfr-clarify-05.txt November 2002 - - - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires May 2003 [Page 7] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt deleted file mode 100644 index 07749d9..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt +++ /dev/null @@ -1,674 +0,0 @@ - - - - -DNSEXT M. Stapp -Internet-Draft Cisco Systems, Inc. -Expires: September 1, 2006 T. Lemon - Nominum, Inc. - A. Gustafsson - Araneus Information Systems Oy - February 28, 2006 - - - A DNS RR for Encoding DHCP Information (DHCID RR) - <draft-ietf-dnsext-dhcid-rr-12.txt> - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 1, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - It is possible for DHCP clients to attempt to update the same DNS - FQDN or attempt to update a DNS FQDN that has been added to the DNS - for another purpose as they obtain DHCP leases. Whether the DHCP - server or the clients themselves perform the DNS updates, conflicts - can arise. To resolve such conflicts, "Resolution of DNS Name - - - -Stapp, et al. Expires September 1, 2006 [Page 1] - -Internet-Draft The DHCID RR February 2006 - - - Conflicts" [1] proposes storing client identifiers in the DNS to - unambiguously associate domain names with the DHCP clients to which - they refer. This memo defines a distinct RR type for this purpose - for use by DHCP clients and servers, the "DHCID" RR. - - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 3 - 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4 - 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4 - 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4 - 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5 - 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5 - 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5 - 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6 - 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 - 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 - 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7 - 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 - Intellectual Property and Copyright Statements . . . . . . . . . . 12 - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires September 1, 2006 [Page 2] - -Internet-Draft The DHCID RR February 2006 - - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [2]. - - -2. Introduction - - A set of procedures to allow DHCP [6] [10] clients and servers to - automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed - in "Resolution of DNS Name Conflicts" [1]. - - Conflicts can arise if multiple DHCP clients wish to use the same DNS - name or a DHCP client attempts to use a name added for another - purpose. To resolve such conflicts, "Resolution of DNS Name - Conflicts" [1] proposes storing client identifiers in the DNS to - unambiguously associate domain names with the DHCP clients using - them. In the interest of clarity, it is preferable for this DHCP - information to use a distinct RR type. This memo defines a distinct - RR for this purpose for use by DHCP clients or servers, the "DHCID" - RR. - - In order to obscure potentially sensitive client identifying - information, the data stored is the result of a one-way SHA-256 hash - computation. The hash includes information from the DHCP client's - message as well as the domain name itself, so that the data stored in - the DHCID RR will be dependent on both the client identification used - in the DHCP protocol interaction and the domain name. This means - that the DHCID RDATA will vary if a single client is associated over - time with more than one name. This makes it difficult to 'track' a - client as it is associated with various domain names. - - -3. The DHCID RR - - The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The - DHCID RR is only defined in the IN class. DHCID RRs cause no - additional section processing. The DHCID RR is not a singleton type. - -3.1. DHCID RDATA format - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - octets of binary data. The format of this data and its - interpretation by DHCP servers and clients are described below. - - DNS software should consider the RDATA section to be opaque. DHCP - clients or servers use the DHCID RR to associate a DHCP client's - - - -Stapp, et al. Expires September 1, 2006 [Page 3] - -Internet-Draft The DHCID RR February 2006 - - - identity with a DNS name, so that multiple DHCP clients and servers - may deterministically perform dynamic DNS updates to the same zone. - From the updater's perspective, the DHCID resource record RDATA - consists of a 2-octet identifier type, in network byte order, - followed by a 1-octet digest type, followed by one or more octets - representing the actual identifier: - - < 2 octets > Identifier type code - < 1 octet > Digest type code - < n octets > Digest (length depends on digest type) - -3.2. DHCID Presentation Format - - In DNS master files, the RDATA is represented as a single block in - base 64 encoding identical to that used for representing binary data - in RFC 3548 [7]. The data may be divided up into any number of white - space separated substrings, down to single base 64 digits, which are - concatenated to form the complete RDATA. These substrings can span - lines using the standard parentheses. - -3.3. The DHCID RR Identifier Type Codes - - The DHCID RR Identifier Type Code specifies what data from the DHCP - client's request was used as input into the hash function. The - identifier type codes are defined in a registry maintained by IANA, - as specified in Section 7. The initial list of assigned values for - the identifier type code is: - - 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6]. - 0x0001 = The data octets (i.e., the Type and Client-Identifier - fields) from a DHCPv4 client's Client Identifier option [9]. - 0x0002 = The client's DUID (i.e., the data octets of a DHCPv6 - client's Client Identifier option [10] or the DUID field from a - DHCPv4 client's Client Identifier option [12]). - - 0x0003 - 0xfffe = Available to be assigned by IANA. - - 0xffff = RESERVED - -3.4. The DHCID RR Digest Type Code - - The DHCID RR Digest Type Code is an identifier for the digest - algorithm used. The digest is calculated over an identifier and the - canonical FQDN as described in the next section. - - The digest type codes are defined in a registry maintained by IANA, - as specified in Section 7. The initial list of assigned values for - the digest type codes is: value 0 is reserved and value 1 is SHA-256. - - - -Stapp, et al. Expires September 1, 2006 [Page 4] - -Internet-Draft The DHCID RR February 2006 - - - Reserving other types requires IETF standards action. Defining new - values will also require IETF standards action to document how DNS - updaters are to deal with multiple digest types. - -3.5. Computation of the RDATA - - The DHCID RDATA is formed by concatenating the 2-octet identifier - type code with variable-length data. - - The RDATA for all type codes other than 0xffff, which is reserved for - future expansion, is formed by concatenating the 2-octet identifier - type code, the 1-octet digest type code, and the digest value (32 - octets for SHA-256). - - < identifier-type > < digest-type > < digest > - - The input to the digest hash function is defined to be: - - digest = SHA-256(< identifier > < FQDN >) - - The FQDN is represented in the buffer in unambiguous canonical form - as described in RFC 4034 [8], section 6.1. The identifier type code - and the identifier are related as specified in Section 3.3: the - identifier type code describes the source of the identifier. - - A DHCPv4 updater uses the 0x0002 type code if a Client Identifier - option is present in the DHCPv4 messages and it is encoded as - specified in [12]. Otherwise, the updater uses 0x0001 if a Client - Identifier option is present and 0x0000 if not. - - A DHCPv6 updater always uses the 0x0002 type code. - -3.5.1. Using the Client's DUID - - When the updater is using the Client's DUID (either from a DHCPv6 - Client Identifier option or from a portion of the DHCPv4 Client - Identifier option encoded as specified in [12]), the first two octets - of the DHCID RR MUST be 0x0002, in network byte order. The third - octet is the digest type code (1 for SHA-256). The rest of the DHCID - RR MUST contain the results of computing the SHA-256 hash across the - octets of the DUID followed by the FQDN. - -3.5.2. Using the Client Identifier Option - - When the updater is using the DHCPv4 Client Identifier option sent by - the client in its DHCPREQUEST message, the first two octets of the - DHCID RR MUST be 0x0001, in network byte order. The third octet is - the digest type code (1 for SHA-256). The rest of the DHCID RR MUST - - - -Stapp, et al. Expires September 1, 2006 [Page 5] - -Internet-Draft The DHCID RR February 2006 - - - contain the results of computing the SHA-256 hash across the data - octets (i.e., the Type and Client-Identifier fields) of the option, - followed by the FQDN. - -3.5.3. Using the Client's htype and chaddr - - When the updater is using the client's link-layer address as the - identifier, the first two octets of the DHCID RDATA MUST be zero. - The third octet is the digest type code (1 for SHA-256). To generate - the rest of the resource record, the updater computes a one-way hash - using the SHA-256 algorithm across a buffer containing the client's - network hardware type, link-layer address, and the FQDN data. - Specifically, the first octet of the buffer contains the network - hardware type as it appeared in the DHCP 'htype' field of the - client's DHCPREQUEST message. All of the significant octets of the - 'chaddr' field in the client's DHCPREQUEST message follow, in the - same order in which the octets appear in the DHCPREQUEST message. - The number of significant octets in the 'chaddr' field is specified - in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as - specified above, follows. - -3.6. Examples - -3.6.1. Example 1 - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client with - Ethernet MAC address 01:02:03:04:05:06 using domain name - "client.example.com" uses the client's link-layer address to identify - the client. The DHCID RDATA is composed by setting the two type - octets to zero, the 1-octet digest type to 1 for SHA-256, and - performing an SHA-256 hash computation across a buffer containing the - Ethernet MAC type octet, 0x01, the six octets of MAC address, and the - domain name (represented as specified in Section 3.5). - - client.example.com. A 10.0.0.1 - client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V - ytcKD//7es/deY= ) - - If the DHCID RR type is not supported, the RDATA would be encoded - [13] as: - - \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283 - fffedeb3f75e6 ) - -3.6.2. Example 2 - - A DHCP server allocates the IPv4 address 10.0.12.99 to a client which - included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c - - - -Stapp, et al. Expires September 1, 2006 [Page 6] - -Internet-Draft The DHCID RR February 2006 - - - in its DHCP request. The server updates the name "chi.example.com" - on the client's behalf, and uses the DHCP client identifier option - data as input in forming a DHCID RR. The DHCID RDATA is formed by - setting the two type octets to the value 0x0001, the 1-octet digest - type to 1 for SHA-256, and performing a SHA-256 hash computation - across a buffer containing the seven octets from the client-id option - and the FQDN (represented as specified in Section 3.5). - - chi.example.com. A 10.0.12.99 - chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW - L3b/NaiUDlW2No= ) - - If the DHCID RR type is not supported, the RDATA would be encoded - [13] as: - - \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd - 6a2503956d8da ) - -3.6.3. Example 3 - - A DHCP server allocates the IPv6 address 2000::1234:5678 to a client - which included the DHCPv6 client-identifier option data 00:01:00:06: - 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server - updates the name "chi6.example.com" on the client's behalf, and uses - the DHCP client identifier option data as input in forming a DHCID - RR. The DHCID RDATA is formed by setting the two type octets to the - value 0x0002, the 1-octet digest type to 1 for SHA-256, and - performing a SHA-256 hash computation across a buffer containing the - 14 octets from the client-id option and the FQDN (represented as - specified in Section 3.5). - - chi6.example.com. AAAA 2000::1234:5678 - chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l - OjxfNuVAA2kjEA= ) - - If the DHCID RR type is not supported, the RDATA would be encoded - [13] as: - - \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd - b95000da48c40 ) - - -4. Use of the DHCID RR - - This RR MUST NOT be used for any purpose other than that detailed in - "Resolution of DNS Name Conflicts" [1]. Although this RR contains - data that is opaque to DNS servers, the data must be consistent - across all entities that update and interpret this record. - - - -Stapp, et al. Expires September 1, 2006 [Page 7] - -Internet-Draft The DHCID RR February 2006 - - - Therefore, new data formats may only be defined through actions of - the DHC Working Group, as a result of revising [1]. - - -5. Updater Behavior - - The data in the DHCID RR allows updaters to determine whether more - than one DHCP client desires to use a particular FQDN. This allows - site administrators to establish policy about DNS updates. The DHCID - RR does not establish any policy itself. - - Updaters use data from a DHCP client's request and the domain name - that the client desires to use to compute a client identity hash, and - then compare that hash to the data in any DHCID RRs on the name that - they wish to associate with the client's IP address. If an updater - discovers DHCID RRs whose RDATA does not match the client identity - that they have computed, the updater SHOULD conclude that a different - client is currently associated with the name in question. The - updater SHOULD then proceed according to the site's administrative - policy. That policy might dictate that a different name be selected, - or it might permit the updater to continue. - - -6. Security Considerations - - The DHCID record as such does not introduce any new security problems - into the DNS. In order to obscure the client's identity information, - a one-way hash is used. And, in order to make it difficult to - 'track' a client by examining the names associated with a particular - hash value, the FQDN is included in the hash computation. Thus, the - RDATA is dependent on both the DHCP client identification data and on - each FQDN associated with the client. - - However, it should be noted that an attacker that has some knowledge, - such as of MAC addresses commonly used in DHCP client identification - data, may be able to discover the client's DHCP identify by using a - brute-force attack. Even without any additional knowledge, the - number of unknown bits used in computing the hash is typically only - 48 to 80. - - Administrators should be wary of permitting unsecured DNS updates to - zones, whether or not they are exposed to the global Internet. Both - DHCP clients and servers SHOULD use some form of update - authentication (e.g., TSIG [11]) when performing DNS updates. - - -7. IANA Considerations - - - - -Stapp, et al. Expires September 1, 2006 [Page 8] - -Internet-Draft The DHCID RR February 2006 - - - IANA is requested to allocate a DNS RR type number for the DHCID - record type. - - This specification defines a new number-space for the 2-octet - identifier type codes associated with the DHCID RR. IANA is - requested to establish a registry of the values for this number- - space. Three initial values are assigned in Section 3.3, and the - value 0xFFFF is reserved for future use. New DHCID RR identifier - type codes are assigned through Standards Action, as defined in RFC - 2434 [5]. - - This specification defines a new number-space for the 1-octet digest - type codes associated with the DHCID RR. IANA is requested to - establish a registry of the values for this number-space. Two - initial values are assigned in Section 3.4. New DHCID RR digest type - codes are assigned through Standards Action, as defined in RFC 2434 - [5]. - - -8. Acknowledgements - - Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson, - Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie - Volz for their review and suggestions. - - -9. References - -9.1. Normative References - - [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among - DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [4] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - - - - - - -Stapp, et al. Expires September 1, 2006 [Page 9] - -Internet-Draft The DHCID RR February 2006 - - -9.2. Informative References - - [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [11] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers - for Dynamic Host Configuration Protocol Version Four (DHCPv4)", - RFC 4361, February 2006. - - [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires September 1, 2006 [Page 10] - -Internet-Draft The DHCID RR February 2006 - - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxborough, MA 01719 - USA - - Phone: 978.936.1535 - Email: mjs@cisco.com - - - Ted Lemon - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - Email: mellon@nominum.com - - - Andreas Gustafsson - Araneus Information Systems Oy - Ulappakatu 1 - 02320 Espoo - Finland - - Email: gson@araneus.fi - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires September 1, 2006 [Page 11] - -Internet-Draft The DHCID RR February 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Stapp, et al. Expires September 1, 2006 [Page 12] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt deleted file mode 100644 index 438e800..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt +++ /dev/null @@ -1,1397 +0,0 @@ -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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt deleted file mode 100644 index bcc2b4e..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt +++ /dev/null @@ -1,442 +0,0 @@ - - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt deleted file mode 100644 index 3a800f9..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt deleted file mode 100644 index ee03583..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt +++ /dev/null @@ -1,784 +0,0 @@ - - - -DNSEXT D. Blacka -Internet-Draft Verisign, Inc. -Expires: January 19, 2006 July 18, 2005 - - - DNSSEC Experiments - draft-ietf-dnsext-dnssec-experiments-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 January 19, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - In the long history of the development of the DNS security extensions - [1] (DNSSEC), a number of alternate methodologies and modifications - have been proposed and rejected for practical, rather than strictly - technical, reasons. There is a desire to be able to experiment with - these alternate methods in the public DNS. This document describes a - methodology for deploying alternate, non-backwards-compatible, DNSSEC - methodologies in an experimental fashion without disrupting the - deployment of standard DNSSEC. - - - - -Blacka Expires January 19, 2006 [Page 1] - -Internet-Draft DNSSEC Experiments July 2005 - - -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. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . 14 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 2] - -Internet-Draft DNSSEC Experiments July 2005 - - -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [4]) and the DNS security extensions ([1], [2], and [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 [5]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 3] - -Internet-Draft DNSSEC Experiments July 2005 - - -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 DNSSEC-aware resolvers. - - This document describes a standard methodology for setting up public - 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 DNSSEC-aware resolvers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 4] - -Internet-Draft DNSSEC Experiments July 2005 - - -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 server that do implement the DNSSEC - standard. - - Non-Backwards-Compatible: describes experiments that would cause a - standard DNSSEC-aware resolver to (incorrectly) determine that all - or part of a zone is bogus, or to otherwise not interoperable 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 could be used - if desired. - - Note that, in essence, this metholodolgy would also be used to - introduce a new DNSSEC algorithm, independently from any DNSSEC - experimental protocol change. - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 5] - -Internet-Draft DNSSEC Experiments July 2005 - - -4. Method - - The core of the methodology is the use of strictly "unknown" - algorithms to sign the experimental zone, and more importantly, - having only unknown algorithm 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 - algorithms. From [3], 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 unlikely that a validator would not implement the behavior, or, - more to the point, it will not violate this behavior in an unsafe way - (see below (Section 6).) - - Because we are talking about experiments, it is RECOMMENDED that - private algorithm numbers be used (see [2], appendix A.1.1. Note - that secure handling of private algorithms requires special handing - by the validator logic. See [6] for futher 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 RECOMMENDED 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 will - - - -Blacka Expires January 19, 2006 [Page 6] - -Internet-Draft DNSSEC Experiments July 2005 - - - suffice. - - Using this method, resolvers (or, more specificially, 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 DNSSEC-aware servers and - resolvers: servers and resolvers that are aware of the experiment - (and thus recognize the experiments algorithm identifiers and - experimental semantics), and servers and resolvers that are unware 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 - isn't. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 7] - -Internet-Draft DNSSEC Experiments July 2005 - - -5. Defining an Experiment - - The DNSSEC experiment must define the particular set of (previously - unknown) algorithms 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 (see below (Section 9).) - - For example, an experiment might specify in its description the DNS - name "dnssec-experiment-a.example.com" as the base name, and provide - the mapping of "3.dnssec-experiment-a.example.com" is an alias of - DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is - an alias of DNSSEC algorithm 5 (RSASHA1). - - Resolvers MUST then only recognize the experiment's semantics when - present in a zone signed by one or more of these private algorithms. - - In general, however, 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 January 19, 2006 [Page 8] - -Internet-Draft DNSSEC Experiments July 2005 - - -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 the not validatable response and - conclude that the response is bogus, either due to local policy - or implementation details. This is not expected to be the common - case, however. - - 2. In general, it will not be possible for DNSSEC-aware resolvers - not aware of the experiment to build a chain of trust through an - experimental zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 9] - -Internet-Draft DNSSEC Experiments July 2005 - - -7. Transitions - - If an experiment is successful, there may be a desire to move the - experiment to a standards-track extension. One way to do so would be - to move from private algorithm numbers to IANA allocated algorithm - numbers, with otherwise the same meaning. This would still leave a - divide between resolvers that understood the extension versus - resolvers that did not. It would, in essence, create an additional - version of DNSSEC. - - An alternate technique might be to do a typecode rollover, thus - actually creating a definitive new version of DNSSEC. There may be - other transition techniques available, as well. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 10] - -Internet-Draft DNSSEC Experiments July 2005 - - -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 January 19, 2006 [Page 11] - -Internet-Draft DNSSEC Experiments July 2005 - - -9. IANA Considerations - - IANA may need to allocate new DNSSEC algorithm numbers if that - transition approach is taken, or the experiment decides to use - allocated numbers to begin with. No IANA action is required to - deploy an experiment using private algorithm identifiers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 12] - -Internet-Draft DNSSEC Experiments July 2005 - - -10. References - -10.1 Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - -10.2 Informative References - - [4] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [6] Weiler, S., "Clarifications and Implementation Notes for - DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in - progress), March 2005. - - -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 January 19, 2006 [Page 13] - -Internet-Draft DNSSEC Experiments 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. - - - - -Blacka Expires January 19, 2006 [Page 14] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt deleted file mode 100644 index 7503c66..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt +++ /dev/null @@ -1,616 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc -Updates: 4034, 4035 (if approved) J. Ihren -Expires: July 24, 2006 Autonomica AB - January 20, 2006 - - - Minimally Covering NSEC Records and DNSSEC On-line Signing - draft-ietf-dnsext-dnssec-online-signing-02 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 24, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes how to construct DNSSEC NSEC resource records - that cover a smaller range of names than called for by RFC4034. By - generating and signing these records on demand, authoritative name - servers can effectively stop the disclosure of zone contents - otherwise made possible by walking the chain of NSEC records in a - signed zone. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 1] - -Internet-Draft NSEC Epsilon January 2006 - - -Changes from ietf-01 to ietf-02 - - Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG - and NSEC bits set, to be consistent with DNSSECbis -- previous text - said SHOULD. - - Made the applicability statement a little less oppressive. - -Changes from ietf-00 to ietf-01 - - Added an applicability statement, making reference to ongoing work on - NSEC3. - - Added the phrase "epsilon functions", which has been commonly used to - describe the technique and already appeared in the header of each - page, in place of "increment and decrement functions". Also added an - explanatory sentence. - - Corrected references from 4034 section 6.2 to section 6.1. - - Fixed an out-of-date reference to [-bis] and other typos. - - Replaced IANA Considerations text. - - Escaped close parentheses in examples. - - Added some more acknowledgements. - -Changes from weiler-01 to ietf-00 - - Inserted RFC numbers for 4033, 4034, and 4035. - - Specified contents of bitmap field in synthesized NSEC RR's, pointing - out that this relaxes a constraint in 4035. Added 4035 to the - Updates header. - -Changes from weiler-00 to weiler-01 - - Clarified that this updates RFC4034 by relaxing requirements on the - next name field. - - Added examples covering wildcard names. - - In the 'better functions' section, reiterated that perfect functions - aren't needed. - - Added a reference to RFC 2119. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 2] - -Internet-Draft NSEC Epsilon January 2006 - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 - 2. Applicability of This Technique . . . . . . . . . . . . . . . 4 - 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5 - 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 - Intellectual Property and Copyright Statements . . . . . . . . . . 11 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 3] - -Internet-Draft NSEC Epsilon January 2006 - - -1. Introduction and Terminology - - With DNSSEC [1], an NSEC record lists the next instantiated name in - its zone, proving that no names exist in the "span" between the - NSEC's owner name and the name in the "next name" field. In this - document, an NSEC record is said to "cover" the names between its - owner name and next name. - - Through repeated queries that return NSEC records, it is possible to - retrieve all of the names in the zone, a process commonly called - "walking" the zone. Some zone owners have policies forbidding zone - transfers by arbitrary clients; this side-effect of the NSEC - architecture subverts those policies. - - This document presents a way to prevent zone walking by constructing - NSEC records that cover fewer names. These records can make zone - walking take approximately as many queries as simply asking for all - possible names in a zone, making zone walking impractical. Some of - these records must be created and signed on demand, which requires - on-line private keys. Anyone contemplating use of this technique is - strongly encouraged to review the discussion of the risks of on-line - signing in Section 6. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [4]. - - -2. Applicability of This Technique - - The technique presented here may be useful to a zone owner that wants - to use DNSSEC, is concerned about exposure of its zone contents via - zone walking, and is willing to bear the costs of on-line signing. - - As discussed in Section 6, on-line signing has several security - risks, including an increased likelihood of private keys being - disclosed and an increased risk of denial of service attack. Anyone - contemplating use of this technique is strongly encouraged to review - the discussion of the risks of on-line signing in Section 6. - - Furthermore, at the time this document was published, the DNSEXT - working group was actively working on a mechanism to prevent zone - walking that does not require on-line signing (tentatively called - NSEC3). The new mechanism is likely to expose slightly more - information about the zone than this technique (e.g. the number of - instantiated names), but it may be preferable to this technique. - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 4] - -Internet-Draft NSEC Epsilon January 2006 - - -3. Minimally Covering NSEC Records - - This mechanism involves changes to NSEC records for instantiated - names, which can still be generated and signed in advance, as well as - the on-demand generation and signing of new NSEC records whenever a - name must be proven not to exist. - - In the 'next name' field of instantiated names' NSEC records, rather - than list the next instantiated name in the zone, list any name that - falls lexically after the NSEC's owner name and before the next - instantiated name in the zone, according to the ordering function in - RFC4034 [2] section 6.1. This relaxes the requirement in section - 4.1.1 of RFC4034 that the 'next name' field contains the next owner - name in the zone. This change is expected to be fully compatible - with all existing DNSSEC validators. These NSEC records are returned - whenever proving something specifically about the owner name (e.g. - that no resource records of a given type appear at that name). - - Whenever an NSEC record is needed to prove the non-existence of a - name, a new NSEC record is dynamically produced and signed. The new - NSEC record has an owner name lexically before the QNAME but - lexically following any existing name and a 'next name' lexically - following the QNAME but before any existing name. - - The generated NSEC record's type bitmap MUST have the RRSIG and NSEC - bits set and SHOULD NOT have any other bits set. This relaxes the - requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at - names that did not exist before the zone was signed. - - The functions to generate the lexically following and proceeding - names need not be perfect nor consistent, but the generated NSEC - records must not cover any existing names. Furthermore, this - technique works best when the generated NSEC records cover as few - names as possible. In this document, the functions that generate the - nearby names are called 'epsilon' functions, a reference to the - mathematical convention of using the greek letter epsilon to - represent small deviations. - - An NSEC record denying the existence of a wildcard may be generated - in the same way. Since the NSEC record covering a non-existent - wildcard is likely to be used in response to many queries, - authoritative name servers using the techniques described here may - want to pregenerate or cache that record and its corresponding RRSIG. - - For example, a query for an A record at the non-instantiated name - example.com might produce the following two NSEC records, the first - denying the existence of the name example.com and the second denying - the existence of a wildcard: - - - -Weiler & Ihren Expires July 24, 2006 [Page 5] - -Internet-Draft NSEC Epsilon January 2006 - - - exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) - - \).com 3600 IN NSEC +.com ( RRSIG NSEC ) - - Before answering a query with these records, an authoritative server - must test for the existence of names between these endpoints. If the - generated NSEC would cover existing names (e.g. exampldd.com or - *bizarre.example.com), a better epsilon function may be used or the - covered name closest to the QNAME could be used as the NSEC owner - name or next name, as appropriate. If an existing name is used as - the NSEC owner name, that name's real NSEC record MUST be returned. - Using the same example, assuming an exampldd.com delegation exists, - this record might be returned from the parent: - - exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) - - Like every authoritative record in the zone, each generated NSEC - record MUST have corresponding RRSIGs generated using each algorithm - (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as - described in RFC4035 [3] section 2.2. To minimize the number of - signatures that must be generated, a zone may wish to limit the - number of algorithms in its DNSKEY RRset. - - -4. Better Epsilon Functions - - Section 6.1 of RFC4034 defines a strict ordering of DNS names. - Working backwards from that definition, it should be possible to - define epsilon functions that generate the immediately following and - preceding names, respectively. This document does not define such - functions. Instead, this section presents functions that come - reasonably close to the perfect ones. As described above, an - authoritative server should still ensure than no generated NSEC - covers any existing name. - - To increment a name, add a leading label with a single null (zero- - value) octet. - - To decrement a name, decrement the last character of the leftmost - label, then fill that label to a length of 63 octets with octets of - value 255. To decrement a null (zero-value) octet, remove the octet - -- if an empty label is left, remove the label. Defining this - function numerically: fill the left-most label to its maximum length - with zeros (numeric, not ASCII zeros) and subtract one. - - In response to a query for the non-existent name foo.example.com, - these functions produce NSEC records of: - - - - -Weiler & Ihren Expires July 24, 2006 [Page 6] - -Internet-Draft NSEC Epsilon January 2006 - - - fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) - - \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 - \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) - - The first of these NSEC RRs proves that no exact match for - foo.example.com exists, and the second proves that there is no - wildcard in example.com. - - Both of these functions are imperfect: they don't take into account - constraints on number of labels in a name nor total length of a name. - As noted in the previous section, though, this technique does not - depend on the use of perfect epsilon functions: it is sufficient to - test whether any instantiated names fall into the span covered by the - generated NSEC and, if so, substitute those instantiated owner names - for the NSEC owner name or next name, as appropriate. - - -5. IANA Considerations - - This document specifies no IANA Actions. - - -6. Security Considerations - - This approach requires on-demand generation of RRSIG records. This - creates several new vulnerabilities. - - First, on-demand signing requires that a zone's authoritative servers - have access to its private keys. Storing private keys on well-known - internet-accessible servers may make them more vulnerable to - unintended disclosure. - - Second, since generation of digital signatures tends to be - computationally demanding, the requirement for on-demand signing - makes authoritative servers vulnerable to a denial of service attack. - - Lastly, if the epsilon functions are predictable, on-demand signing - may enable a chosen-plaintext attack on a zone's private keys. Zones - using this approach should attempt to use cryptographic algorithms - that are resistant to chosen-plaintext attacks. It's worth noting - - - -Weiler & Ihren Expires July 24, 2006 [Page 7] - -Internet-Draft NSEC Epsilon January 2006 - - - that while DNSSEC has a "mandatory to implement" algorithm, that is a - requirement on resolvers and validators -- there is no requirement - that a zone be signed with any given algorithm. - - The success of using minimally covering NSEC record to prevent zone - walking depends greatly on the quality of the epsilon functions - chosen. An increment function that chooses a name obviously derived - from the next instantiated name may be easily reverse engineered, - destroying the value of this technique. An increment function that - always returns a name close to the next instantiated name is likewise - a poor choice. Good choices of epsilon functions are the ones that - produce the immediately following and preceding names, respectively, - though zone administrators may wish to use less perfect functions - that return more human-friendly names than the functions described in - Section 4 above. - - Another obvious but misguided concern is the danger from synthesized - NSEC records being replayed. It's possible for an attacker to replay - an old but still validly signed NSEC record after a new name has been - added in the span covered by that NSEC, incorrectly proving that - there is no record at that name. This danger exists with DNSSEC as - defined in [3]. The techniques described here actually decrease the - danger, since the span covered by any NSEC record is smaller than - before. Choosing better epsilon functions will further reduce this - danger. - -7. Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - -Appendix A. Acknowledgments - - Many individuals contributed to this design. They include, in - addition to the authors of this document, Olaf Kolkman, Ed Lewis, - - - -Weiler & Ihren Expires July 24, 2006 [Page 8] - -Internet-Draft NSEC Epsilon January 2006 - - - Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, - Jakob Schlyter, Bill Manning, and Joao Damas. - - In addition, the editors would like to thank Ed Lewis, Scott Rose, - and David Blacka for their careful review of the document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 9] - -Internet-Draft NSEC Epsilon January 2006 - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc - 7075 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - Johan Ihren - Autonomica AB - Bellmansgatan 30 - Stockholm SE-118 47 - Sweden - - Email: johani@autonomica.se - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Ihren Expires July 24, 2006 [Page 10] - -Internet-Draft NSEC Epsilon January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Weiler & Ihren Expires July 24, 2006 [Page 11] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt deleted file mode 100644 index 17e28e8..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt +++ /dev/null @@ -1,896 +0,0 @@ - - - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt deleted file mode 100644 index 390420a..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt +++ /dev/null @@ -1,392 +0,0 @@ - - - -DNS Extensions working group J. Jansen -Internet-Draft NLnet Labs -Expires: July 5, 2006 January 2006 - - - Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC - draft-ietf-dnsext-dnssec-rsasha256-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 5, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG - resource records for use in the Domain Name System Security - Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). - - - - - - - - - -Jansen Expires July 5, 2006 [Page 1] - -Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3 - 3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3 - 4. Implementation Considerations . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 - Intellectual Property and Copyright Statements . . . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jansen Expires July 5, 2006 [Page 2] - -Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical distributed - database for Internet Addressing. The DNS has been extended to use - digital signatures and cryptographic keys for the verification of - data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS - Security Extensions. - - RFC4034 describes how to store DNSKEY and RRSIG resource records, and - specifies a list of cryptographic algorithms to use. This document - extends that list with the algorithm RSA/SHA-256, and specifies how - to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG - resource records. - - Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in - this document. - - -2. RSA/SHA-256 DNSKEY Resource Records - - RSA public keys for use with RSA/SHA-256 are stored in DNSKEY - resource records (RRs) with the algorithm number [TBA]. - - The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 - [6]. - - -3. RSA/SHA-256 RRSIG Resource Records - - RSA/SHA-256 signatures are stored in the DNS using RRSIG resource - records (RRs) with algorithm number [TBA]. - - The value of the signature field in the RRSIG RR is calculated as - follows. The values for the fields that precede the signature data - are specified in RFC4034 [2]. - - hash = SHA-256(data) - - signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) - - Where SHA-256 is the message digest algorithm as specified in FIPS - 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of - corresponding hexadecimal value, "e" is the private exponent of the - signing RSA key, and "n" is the public modulus of the signing key. - The FF octet MUST be repeated the maximum number of times so that the - total length of the signature equals the length of the modulus of the - signer's public key ("n"). "data" is the data of the resource record - set that is signed, as specified in RFC4034 [2]. - - - -Jansen Expires July 5, 2006 [Page 3] - -Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 - - - The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as - specified in PKCS 2.1 [4]: - - hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 - - This prefix should make the use of standard cryptographic libraries - easier. These specifications are taken directly from PKCS #1 v2.1 - section 9.2 [4]. - - -4. Implementation Considerations - - DNSSEC aware implementations MUST be able to support RRSIG resource - records with the RSA/SHA-256 algorithm. - - If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are - available for a certain rrset, with a secure path to their keys, the - validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256 - signature does not verify the data, and the RSA/SHA-1 does, the - validator SHOULD mark the data with the security status from the RSA/ - SHA-256 signature. - - -5. IANA Considerations - - IANA has not yet assigned an algorithm number for RSA/SHA-256. - - The algorithm list from RFC4034 Appendix A.1 [2] is extended with the - following entry: - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- ----------- ----------- -------- ---------- --------- - [tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY - - -6. Security Considerations - - Recently, weaknesses have been discovered in the SHA-1 hashing - algorithm. It is therefore strongly encouraged to deploy SHA-256 - where SHA-1 is used now, as soon as the DNS software supports it. - - SHA-256 is considered sufficiently strong for the immediate future, - but predictions about future development in cryptography and - cryptanalysis are beyond the scope of this document. - - - - - - -Jansen Expires July 5, 2006 [Page 4] - -Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 - - -7. Acknowledgments - - This document is a minor extension to RFC4034 [2]. Also, we try to - follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt - [8] for consistency. The authors of and contributors to these - documents are gratefully acknowledged for their hard work. - - The following people provided additional feedback and text: Jaap - Akkerhuis, Miek Gieben and Wouter Wijngaards. - - -8. References - -8.1. Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards - (PKCS) #1: RSA Cryptography Specifications Version 2.1", - RFC 3447, February 2003. - - [5] National Institute of Standards and Technology, "Secure Hash - Standard", FIPS PUB 180-2, August 2002. - - [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - -8.2. Informative References - - [7] Schneier, B., "Applied Cryptography Second Edition: protocols, - algorithms, and source code in C", Wiley and Sons , ISBN 0-471- - 11709-9, 1996. - - [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) - Resource Records (RRs)", Work in Progress Feb 2006. - - - - - - -Jansen Expires July 5, 2006 [Page 5] - -Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 - - -Author's Address - - Jelte Jansen - NLnet Labs - Kruislaan 419 - Amsterdam 1098VA - NL - - Email: jelte@NLnetLabs.nl - URI: http://www.nlnetlabs.nl/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jansen Expires July 5, 2006 [Page 6] - -Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Jansen Expires July 5, 2006 [Page 7] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt deleted file mode 100644 index dd8cbf0..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt +++ /dev/null @@ -1,839 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt deleted file mode 100644 index 2460cb6..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - -Network Working Group W. Hardaker -Internet-Draft Sparta -Expires: August 25, 2006 February 21, 2006 - - - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) - draft-ietf-dnsext-ds-sha256-05.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 25, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies how to use the SHA-256 digest type in DNS - Delegation Signer (DS) Resource Records (RRs). DS records, when - stored in a parent zone, point to key signing DNSKEY key(s) in a - child zone. - - - - - - - - -Hardaker Expires August 25, 2006 [Page 1] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementing the SHA-256 algorithm for DS record support . . . 3 - 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3 - 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3 - 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4 - 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4 - 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 - 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5 - 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 2] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -1. Introduction - - The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent - zones to distribute a cryptographic digest of a child's Key Signing - Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the - parent zone's private zone data signing keys for each algorithm in - use by the parent. Each signature is published in an RRSIG resource - record, owned by the same domain as the DS RRset and with a type - covered of DS. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Implementing the SHA-256 algorithm for DS record support - - This document specifies that the digest type code [XXX: To be - assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] - [SHA256CODE] for use within DS records. The results of the digest - algorithm MUST NOT be truncated and the entire 32 byte digest result - is to be published in the DS record. - -2.1. DS record field values - - Using the SHA-256 digest algorithm within a DS record will make use - of the following DS-record fields: - - Digest type: [XXX: To be assigned by IANA; likely 2] - - Digest: A SHA-256 bit digest value calculated by using the following - formula ("|" denotes concatenation). The resulting value is not - truncated and the entire 32 byte result is to used in the - resulting DS record and related calculations. - - digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) - - where DNSKEY RDATA is defined by [RFC4034] as: - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key - - The Key Tag field and Algorithm fields remain unchanged by this - document and are specified in the [RFC4034] specification. - -2.2. DS Record with SHA-256 Wire Format - - The resulting on-the-wire format for the resulting DS record will be - [XXX: IANA assignment should replace the 2 below]: - - - -Hardaker Expires August 25, 2006 [Page 3] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | DigestType=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest (length for SHA-256 is 32 bytes) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - -2.3. Example DS Record Using SHA-256 - - The following is an example DNSKEY and matching DS record. This - DNSKEY record comes from the example DNSKEY/DS records found in - section 5.4 of [RFC4034]. - - The DNSKEY record: - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - The resulting DS record covering the above DNSKEY record using a SHA- - 256 digest: [RFC Editor: please replace XXX with the assigned digest - type (likely 2):] - - dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C - CEB1E3E0614B93C4F9E99B83 - 83F6A1E4469DA50A ) - - -3. Implementation Requirements - - Implementations MUST support the use of the SHA-256 algorithm in DS - RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 - digests if DS RRs with SHA-256 digests are present in the DS RRset. - - -4. Deployment Considerations - - If a validator does not support the SHA-256 digest type and no other - DS RR exists in a zone's DS RRset with a supported digest type, then - - - -Hardaker Expires August 25, 2006 [Page 4] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - the validator has no supported authentication path leading from the - parent to the child. The resolver should treat this case as it would - the case of an authenticated NSEC RRset proving that no DS RRset - exists, as described in [RFC4035], section 5.2. - - Because zone administrators can not control the deployment speed of - support for SHA-256 in validators that may be referencing any of - their zones, zone operators should consider deploying both SHA-1 and - SHA-256 based DS records. This should be done for every DNSKEY for - which DS records are being generated. Whether to make use of both - digest types and for how long is a policy decision that extends - beyond the scope of this document. - - -5. IANA Considerations - - Only one IANA action is required by this document: - - The Digest Type to be used for supporting SHA-256 within DS records - needs to be assigned by IANA. This document requests that the Digest - Type value of 2 be assigned to the SHA-256 digest algorithm. - - At the time of this writing, the current digest types assigned for - use in DS records are as follows: - - VALUE Digest Type Status - 0 Reserved - - 1 SHA-1 MANDATORY - 2 SHA-256 MANDATORY - 3-255 Unassigned - - - -6. Security Considerations - -6.1. Potential Digest Type Downgrade Attacks - - A downgrade attack from a stronger digest type to a weaker one is - possible if all of the following are true: - - o A zone includes multiple DS records for a given child's DNSKEY, - each of which use a different digest type. - - o A validator accepts a weaker digest even if a stronger one is - present but invalid. - - For example, if the following conditions are all true: - - - - - -Hardaker Expires August 25, 2006 [Page 5] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - - o Both SHA-1 and SHA-256 based digests are published in DS records - within a parent zone for a given child zone's DNSKEY. - - o The DS record with the SHA-1 digest matches the digest computed - using the child zone's DNSKEY. - - o The DS record with the SHA-256 digest fails to match the digest - computed using the child zone's DNSKEY. - - Then if the validator accepts the above situation as secure then this - can be used as a downgrade attack since the stronger SHA-256 digest - is ignored. - -6.2. SHA-1 vs SHA-256 Considerations for DS Records - - Users of DNSSEC are encouraged to deploy SHA-256 as soon as software - implementations allow for it. SHA-256 is widely believed to be more - resilient to attack than SHA-1, and confidence in SHA-1's strength is - being eroded by recently-announced attacks. Regardless of whether or - not the attacks on SHA-1 will affect DNSSEC, it is believed (at the - time of this writing) that SHA-256 is the better choice for use in DS - records. - - At the time of this publication, the SHA-256 digest algorithm is - considered sufficiently strong for the immediate future. It is also - considered sufficient for use in DNSSEC DS RRs for the immediate - future. However, future published attacks may weaken the usability - of this algorithm within the DS RRs. It is beyond the scope of this - document to speculate extensively on the cryptographic strength of - the SHA-256 digest algorithm. - - Likewise, it is also beyond the scope of this document to specify - whether or for how long SHA-1 based DS records should be - simultaneously published alongside SHA-256 based DS records. - - -7. Acknowledgments - - This document is a minor extension to the existing DNSSEC documents - and those authors are gratefully appreciated for the hard work that - went into the base documents. - - The following people contributed to portions of this document in some - fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, - Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam - Weiler. - - - - - -Hardaker Expires August 25, 2006 [Page 6] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [SHA256] National Institute of Standards and Technology, "Secure - Hash Algorithm. NIST FIPS 180-2", August 2002. - -8.2. Informative References - - [SHA256CODE] - Eastlake, D., "US Secure Hash Algorithms (SHA)", - June 2005. - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 7] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Author's Address - - Wes Hardaker - Sparta - P.O. Box 382 - Davis, CA 95617 - US - - Email: hardaker@tislabs.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 25, 2006 [Page 8] - -Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Hardaker Expires August 25, 2006 [Page 9] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt deleted file mode 100644 index 2cdcdb1..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt +++ /dev/null @@ -1,928 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt deleted file mode 100644 index 160afc3..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt +++ /dev/null @@ -1,334 +0,0 @@ -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/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt deleted file mode 100644 index 6bffb70..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt +++ /dev/null @@ -1,560 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt deleted file mode 100644 index 5de6e85..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt +++ /dev/null @@ -1,1740 +0,0 @@ - - - - - - -DNSEXT Working Group Bernard Aboba -INTERNET-DRAFT Dave Thaler -Category: Standards Track Levon Esibov -<draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation -29 August 2005 - - 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 March 15, 2006. - -Copyright Notice - - Copyright (C) The Internet Society 2005. - -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 29 August 2005 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 - 1.2 Terminology ..................................... 4 -2. Name Resolution Using LLMNR ........................... 4 - 2.1 LLMNR Packet Format ............................. 6 - 2.2 Sender Behavior ................................. 9 - 2.3 Responder Behavior .............................. 10 - 2.4 Unicast Queries and Responses ................... 12 - 2.5 Off-link Detection .............................. 13 - 2.6 Responder Responsibilities ...................... 13 - 2.7 Retransmission and Jitter ....................... 14 - 2.8 DNS TTL ......................................... 15 - 2.9 Use of the Authority and Additional Sections .... 15 -3. Usage model ........................................... 16 - 3.1 LLMNR Configuration ............................. 17 -4. Conflict Resolution ................................... 18 - 4.1 Uniqueness Verification ......................... 19 - 4.2 Conflict Detection and Defense .................. 20 - 4.3 Considerations for Multiple Interfaces .......... 21 - 4.4 API issues ...................................... 22 -5. Security Considerations ............................... 22 - 5.1 Denial of Service ............................... 23 - 5.2 Spoofing ...............,........................ 23 - 5.3 Authentication .................................. 24 - 5.4 Cache and Port Separation ....................... 25 -6. IANA considerations ................................... 25 -7. Constants ............................................. 25 -8. References ............................................ 25 - 8.1 Normative References ............................ 25 - 8.2 Informative References .......................... 26 -Acknowledgments .............................................. 27 -Authors' Addresses ........................................... 28 -Intellectual Property Statement .............................. 28 -Disclaimer of Validity ....................................... 29 -Copyright Statement .......................................... 29 - - - - - - - - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -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. - - The goal of LLMNR is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. Usage scenarios - (discussed in more detail in Section 3.1) include 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, as described - in Section 2. - - Since LLMNR only operates on the local link, it cannot be considered - a substitute for DNS. Link-scope multicast addresses are used to - prevent propagation of LLMNR traffic across routers, potentially - flooding the network. LLMNR queries can also be sent to a unicast - address, as described in Section 2.4. - - Propagation of LLMNR packets on the local link is considered - sufficient to enable name resolution in small networks. 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. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - -1.2. Terminology - - This document assumes familiarity with DNS terminology defined in - [RFC1035]. Other terminology used in this document includes: - -Positively Resolved - Responses with RCODE set to zero are referred to in this document - as "positively resolved". - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An 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 is a peer-to-peer name resolution protocol that is not intended - as a replacement for DNS. LLMNR queries are sent to and received on - port 5355. 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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]. - - 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. - - By default, LLMNR queries MAY be sent only when 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, then LLMNR - SHOULD NOT be used as the primary name resolution mechanism, - although it MAY be used as a secondary name resolution - mechanism. A dual stack host SHOULD attempt to reach DNS - servers overall 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 inplies 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. - - While these conditions are necessary for sending an LLMNR query, they - are not sufficient. While an LLMNR sender MAY send a query for any - name, it also MAY impose additional conditions on sending LLMNR - - - -Aboba, Thaler & Esibov Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - queries. For example, a sender configured with a DNS server MAY send - LLMNR queries only for unqualified names and for fully qualified - domain names within configured zones. - - A typical sequence of events for LLMNR usage is as follows: - - [a] DNS servers are not configured or attempts to resolve the - name via DNS have failed, after exhausting the searchlist. - Also, the name to be queried satisfies the restrictions - imposed by the implementation. - - [b] An LLMNR sender sends an LLMNR query to the link-scope - multicast address(es), unless a unicast query is indicated, - as specified in Section 2.4. - - [c] A responder responds to this query only if it is authoritative - for the domain name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.4. - - [d] Upon reception of the response, the sender processes it. - - 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: - - - - - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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: - -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. - - - - - -Aboba, Thaler & Esibov Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -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 discard the response and resend the LLMNR - query over TCP using the unicast address of the responder as the - destination address. See [RFC2181] and Section 2.4 of this - specification for further discussion of the TC bit. - -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. - -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. - Errors include those defined in [RFC2845], such as BADSIG(16), - BADKEY(17) and BADTIME(18). - - 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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 - 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - silently discarded. - - 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. - - 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 - 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: - - - - - -Aboba, Thaler & Esibov Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -[a] Responders MUST listen on UDP port 5355 on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port 5355 on - the unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses 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. - -[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. - - - -Aboba, Thaler & Esibov Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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 - 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. - - If TCP connection setup cannot be completed in order to send a - unicast TCP query, this is treated as a response that no records of - the specified type and class exist for the specified name (it is - treated the same as a response with RCODE=0 and an empty answer - section). - - - - - -Aboba, Thaler & Esibov Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -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. - - Section 2.4 discusses use of TCP for LLMNR queries and responses. In - composing an LLMNR query using TCP, the sender MUST set the Hop Limit - field in the IPv6 header and the TTL field in the IPv4 header of the - response to one (1). The responder SHOULD set the TTL or Hop Limit - settings on the TCP listen socket to one (1) so that SYN-ACK packets - will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This - prevents an incoming connection from off-link since the sender will - not receive a SYN-ACK from the responder. - - For UDP queries and responses, the Hop Limit field in the IPv6 header - and the TTL field in the IPV4 header MAY be set to any value. - However, it is RECOMMENDED that the value 255 be used for - compatibility with Apple Bonjour [Bonjour]. - - 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: - - - - -Aboba, Thaler & Esibov Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - [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 - 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, - while increasing the value of LLMNR_TIMEOUT exponentially. 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. - - - -Aboba, Thaler & Esibov Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - However, if the first response has the 'C' bit set, then the sender - SHOULD wait for LLMNR_TIMEOUT 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, so - that it only waits for LLMNR_TIMEOUT if no response has been - 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 and LLMNR_TIMEOUT estimation, 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 - 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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. - -3. Usage Model - - Since LLMNR is a secondary name resolution mechanism, its usage is in - part determined by the behavior of DNS implementations. This - document does not specify any changes to DNS resolver behavior, such - as searchlist processing or retransmission/failover policy. However, - robust DNS resolver implementations are more likely to avoid - unnecessary LLMNR queries. - - As noted in [DNSPerf], even when DNS servers are configured, a - significant fraction of DNS queries do not receive a response, or - result in negative responses due to missing inverse mappings or NS - records that point to nonexistent or inappropriate hosts. This has - the potential to result in a large number of unnecessary LLMNR - queries. - - [RFC1536] describes common DNS implementation errors and fixes. If - the proposed fixes are implemented, unnecessary LLMNR queries will be - reduced substantially, and so implementation of [RFC1536] is - recommended. - - For example, [RFC1536] Section 1 describes issues with retransmission - and recommends implementation of a retransmission policy based on - round trip estimates, with exponential backoff. [RFC1536] Section 4 - describes issues with failover, and recommends that resolvers try - another server when they don't receive a response to a query. These - policies are likely to avoid unnecessary LLMNR queries. - - [RFC1536] Section 3 describes zero answer bugs, which if addressed - - - -Aboba, Thaler & Esibov Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - will also reduce unnecessary LLMNR queries. - - [RFC1536] Section 6 describes name error bugs and recommended - searchlist processing that will reduce unnecessary RCODE=3 - (authoritative name) errors, thereby also reducing unnecessary LLMNR - queries. - -3.1. LLMNR Configuration - - Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is - possible for a dual stack host to be configured with the address of a - DNS server over IPv4, while remaining unconfigured with a DNS server - suitable for use over IPv6. - - In these situations, a dual stack host will send AAAA queries to the - configured DNS server over IPv4. However, an IPv6-only host - unconfigured with a DNS server suitable for use over IPv6 will be - unable to resolve names using DNS. Automatic IPv6 DNS configuration - mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely - deployed, and not all DNS servers support IPv6. Therefore lack of - IPv6 DNS configuration may be a common problem in the short term, and - LLMNR may prove useful in enabling 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - configure LLMNR on an interface. The LLMNR Enable Option, described - in [LLMNREnable], can be used to explicitly enable or disable use of - LLMNR on an interface. The LLMNR Enable Option does not determine - whether or in which order DNS itself is used for name resolution. - The order in which various name resolution mechanisms should be used - can be specified using the Name Service Search Option (NSSO) for DHCP - [RFC2937], using the LLMNR Enable Option code carried in the NSSO - data. - - It is possible that DNS configuration mechanisms will go in and out - of service. In these circumstances, it is possible for hosts within - an administrative domain to be inconsistent in their DNS - configuration. - - For example, where DHCP is used for configuring DNS servers, one or - more DHCP servers can fail. As a result, hosts configured prior to - the outage will be configured with a DNS server, while hosts - configured after the outage will not. Alternatively, it is possible - for the DNS configuration mechanism to continue functioning while - configured DNS servers fail. - - 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. - - - - - - - -Aboba, Thaler & Esibov Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -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 - 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 - - - -Aboba, Thaler & Esibov Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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 - 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. - - - -Aboba, Thaler & Esibov Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -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. - - ---------- ---------- - | | | | - [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 - - - -Aboba, Thaler & Esibov Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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. - -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 - - - -Aboba, Thaler & Esibov Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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 - 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) - - - -Aboba, Thaler & Esibov Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - - 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. - - Limiting the situations in which LLMNR queries are sent, as described - in Section 2, is the best protection against these attacks. 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 is only used as a name resolution mechanism of last resort. - -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. This makes it difficult to apply existing DNS security - mechanisms to LLMNR. - - LLMNR does not support "delegated trust" (CD or AD bits). As a - result, unless LLMNR senders are DNSSEC aware, it is not feasible to - use DNSSEC [RFC4033] with LLMNR. - - If authentication is desired, and a pre-arranged security - configuration is possible, then 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 responses, based on group keys. - - - - -Aboba, Thaler & Esibov Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -[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. - - Where these mechanisms cannot be supported, responses to LLMNR - queries may be unauthenticated. - -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. - -6. IANA Considerations - - This specification creates one new name space: the reserved bits in - the LLMNR header. These are allocated by IETF Consensus, in - accordance with BCP 26 [RFC2434]. - - LLMNR requires allocation of port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 224.0.0.252, as well as link-scope multicast IPv6 address - FF02:0:0:0:0:0:1:3. - -7. 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) - -8. References - -8.1. Normative References - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - - - -Aboba, Thaler & Esibov Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -[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 - -[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft - (work in progress), draft-cheshire-dnsext-multicastdns-05.txt, - June 2005. - -[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. - -[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. - - - -Aboba, Thaler & Esibov Standards Track [Page 26] - - - - - -INTERNET-DRAFT LLMNR 29 August 2005 - - -[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. - -[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. - - - - -Aboba, Thaler & Esibov Standards Track [Page 27] - - - - - -INTERNET-DRAFT LLMNR 29 August 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 - -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. - - - -Aboba, Thaler & Esibov Standards Track [Page 28] - - - - - -INTERNET-DRAFT LLMNR 29 August 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. - -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. - -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 29] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt deleted file mode 100644 index 8c6c5b1..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt +++ /dev/null @@ -1,2352 +0,0 @@ - - - -Network Working Group B. Laurie -Internet-Draft G. Sisson -Expires: August 5, 2006 R. Arends - Nominet - February 2006 - - - DNSSEC Hash Authenticated Denial of Existence - draft-ietf-dnsext-nsec3-04 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 5, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - The DNS Security Extensions introduces the NSEC resource record for - authenticated denial of existence. This document introduces a new - resource record as an alternative to NSEC that provides measures - against zone enumeration and allows for gradual expansion of - delegation-centric zones. - - - - - -Laurie, et al. Expires August 5, 2006 [Page 1] - -Internet-Draft nsec3 February 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5 - 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5 - 3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6 - 3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6 - 3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7 - 3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8 - 3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8 - 3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8 - 3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9 - 3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9 - 3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10 - 4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11 - 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11 - 6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11 - 7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12 - 8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13 - 8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16 - 8.4.1. Avoiding Hash Collisions during generation . . . . . . 16 - 8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16 - 8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17 - 8.4.4. Server Response to a Run-time Collision . . . . . . . 17 - 8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18 - 9. Performance Considerations . . . . . . . . . . . . . . . . . . 18 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22 - Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 27 - B.1. answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - B.1.1. Authenticating the Example DNSKEY RRset . . . . . . . 29 - B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30 - B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . . 32 - B.3.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 33 - B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . . 34 - B.5. Referral to Unsigned Zone using the Opt-In Flag . . . . . 35 - B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36 - - - -Laurie, et al. Expires August 5, 2006 [Page 2] - -Internet-Draft nsec3 February 2006 - - - B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38 - B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . . 39 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 - Intellectual Property and Copyright Statements . . . . . . . . . . 42 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 3] - -Internet-Draft nsec3 February 2006 - - -1. Introduction - -1.1. Rationale - - The DNS Security Extensions included the NSEC RR to provide - authenticated denial of existence. Though the NSEC RR meets the - requirements for authenticated denial of existence, it introduced a - side-effect in that the contents of a zone can be enumerated. This - property introduces undesired policy issues. - - An enumerated zone can be used either directly as a source of - probable e-mail addresses for spam, or indirectly as a key for - multiple WHOIS queries to reveal registrant data which many - registries may be under strict legal obligations to protect. Many - registries therefore prohibit copying of their zone file; however the - use of NSEC RRs renders these policies unenforceable. - - A second problem was the requirement that the existence of all record - types in a zone - including unsigned delegation points - must be - accounted for, despite the fact that unsigned delegation point - records are not signed. This requirement has a side-effect that the - overhead of signed zones is not related to the increase in security - of subzones. This requirement does not allow the zones' size to grow - in relation to the growth of signed subzones. - - In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been - proposed as a measure against these side effects but at the time were - regarded as secondary over the need to have a stable DNSSEC - specification. With (draft-vixie-dnssec-ter) [14] a graceful - transition path to future enhancements is introduced, while current - DNSSEC deployment can continue. This document presents the NSEC3 - Resource Record which mitigates these issues with the NSEC RR. - - The reader is assumed to be familiar with the basic DNS and DNSSEC - concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC - 4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136 - [6], RFC2181 [7] and RFC2308 [8]. - -1.2. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [9]. - -1.3. Terminology - - The practice of discovering the contents of a zone, i.e. enumerating - the domains within a zone, is known as "zone enumeration". Zone - - - -Laurie, et al. Expires August 5, 2006 [Page 4] - -Internet-Draft nsec3 February 2006 - - - enumeration was not practical prior to the introduction of DNSSEC. - - In this document the term "original ownername" refers to a standard - ownername. Because this proposal uses the result of a hash function - over the original (unmodified) ownername, this result is referred to - as "hashed ownername". - - "Hash order" means the order in which hashed ownernames are arranged - according to their numerical value, treating the leftmost (lowest - numbered) octet as the most significant octet. Note that this is the - same as the canonical ordering specified in RFC 4034 [4]. - - An "empty non-terminal" is a domain name that owns no resource - records but has subdomains that do. - - The "closest encloser" of a (nonexistent) domain name is the longest - domain name, including empty non-terminals, that matches the - rightmost part of the nonexistent domain name. - - "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as - specified in RFC 3548bis [15]. - - -2. NSEC versus NSEC3 - - This document does NOT obsolete the NSEC record, but gives an - alternative for authenticated denial of existence. NSEC and NSEC3 - RRs can not co-exist in a zone. See draft-vixie-dnssec-ter [14] for - a signaling mechanism to allow for graceful transition towards NSEC3. - - -3. The NSEC3 Resource Record - - The NSEC3 RR provides Authenticated Denial of Existence for DNS - Resource Record Sets. - - The NSEC3 Resource Record (RR) lists RR types present at the NSEC3 - RR's original ownername. It includes the next hashed ownername in - the hash order of the zone. The complete set of NSEC3 RRs in a zone - indicates which RRsets exist for the original ownername of the RRset - and form a chain of hashed ownernames in the zone. This information - is used to provide authenticated denial of existence for DNS data, as - described in RFC 4035 [5]. To provide protection against zone - enumeration, the ownernames used in the NSEC3 RR are cryptographic - hashes of the original ownername prepended to the name of the zone. - The NSEC3 RR indicates which hash function is used to construct the - hash, which salt is used, and how many iterations of the hash - function are performed over the original ownername. The hashing - - - -Laurie, et al. Expires August 5, 2006 [Page 5] - -Internet-Draft nsec3 February 2006 - - - technique is described fully in Section 5. - - Hashed ownernames of unsigned delegations may be excluded from the - chain. An NSEC3 record which span covers the hash of an unsigned - delegation's ownername is referred to as an Opt-In NSEC3 record and - is indicated by the presence of a flag. - - The ownername for the NSEC3 RR is the base32 encoding of the hashed - ownername prepended to the name of the zone.. - - The type value for the NSEC3 RR is XX. - - The NSEC3 RR RDATA format is class independent and is described - below. - - The class MUST be the same as the original ownername's class. - - The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [8]. - -3.1. NSEC3 RDATA Wire Format - - The RDATA of the NSEC3 RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Hash Function |O| Iterations | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Salt Length | Salt / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Hashed Ownername / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - "O" is the Opt-In Flag field. - -3.1.1. The Hash Function Field - - The Hash Function field identifies the cryptographic hash function - used to construct the hash-value. - - The values are as defined for the DS record (see RFC 3658 [10]). - - On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash - function value. - - - - -Laurie, et al. Expires August 5, 2006 [Page 6] - -Internet-Draft nsec3 February 2006 - - -3.1.2. The Opt-In Flag Field - - The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned - delegations. - - In DNSSEC, NS RRsets at delegation points are not signed, and may be - accompanied by a DS record. The security status of the subzone is - determined by the presence or absence of the DS RRset, - cryptographically proven by the NSEC record or the signed DS RRset. - The presence of the Opt-In flag expands this definition by allowing - insecure delegations to exist within an otherwise signed zone without - the corresponding NSEC3 record at the delegation's (hashed) owner - name. These delegations are proven insecure by using a covering - NSEC3 record. - - Resolvers must be able to distinguish between NSEC3 records and - Opt-In NSEC3 records. This is accomplished by setting the Opt-In - flag of the NSEC3 records that cover (or potentially cover) insecure - delegation nodes. - - An Opt-In NSEC3 record does not assert the existence or non-existence - of the insecure delegations that it covers. This allows for the - addition or removal of these delegations without recalculating or - resigning records in the NSEC3 chain. However, Opt-In NSEC3 records - do assert the (non)existence of other, authoritative RRsets. - - An Opt-In NSEC3 record MAY have the same original owner name as an - insecure delegation. In this case, the delegation is proven insecure - by the lack of a DS bit in type map and the signed NSEC3 record does - assert the existence of the delegation. - - Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and - non-Opt-In NSEC3 records. If an NSEC3 record is not Opt-In, there - MUST NOT be any hashed ownernames of insecure delegations (nor any - other records) between it and the RRsets indicated by the 'Next - Hashed Ownername' in the NSEC3 RDATA. If it is Opt-In, there MUST - only be hashed ownernames of insecure delegations between it and the - next node indicated by the 'Next Hashed Ownername' in the NSEC3 - RDATA. - - In summary, - o An Opt-In NSEC3 type is identified by an Opt-In Flag field value - of 1. - o A non Opt-In NSEC3 type is identified by an Opt-In Flag field - value of 0. - and, - - - - - -Laurie, et al. Expires August 5, 2006 [Page 7] - -Internet-Draft nsec3 February 2006 - - - o An Opt-In NSEC3 record does not assert the non-existence of a hash - ownername between its ownername and next hashed ownername, - although it does assert that any hashed name in this span MUST be - of an insecure delegation. - o An Opt-In NSEC3 record does assert the (non)existence of RRsets - with the same hashed owner name. - -3.1.3. The Iterations Field - - The Iterations field defines the number of times the hash has been - iterated. More iterations results in greater resiliency of the hash - value against dictionary attacks, but at a higher cost for both the - server and resolver. See Section 5 for details of this field's use. - - Iterations make an attack more costly by making the hash computation - more computationally intensive, e.g. by iterating the hash function a - number of times. - - When generating a few hashes this performance loss will not be a - problem, as a validator can handle a delay of a few milliseconds. - But when doing a dictionary attack it will also multiply the attack - workload by a factor, which is a problem for the attacker. - -3.1.4. The Salt Length Field - - The salt length field defines the length of the salt in octets. - -3.1.5. The Salt Field - - The Salt field is not present when the Salt Length Field has a value - of 0. - - The Salt field is appended to the original ownername before hashing - in order to defend against precalculated dictionary attacks. See - Section 5 for details on how the salt is used. - - Salt is used to make dictionary attacks using precomputation more - costly. A dictionary can only be computed after the attacker has the - salt, hence a new salt means that the dictionary has to be - regenerated with the new salt. - - There MUST be a complete set of NSEC3 records covering the entire - zone that use the same salt value. The requirement exists so that, - given any qname within a zone, at least one covering NSEC3 RRset may - be found. While it may be theoretically possible to produce a set of - NSEC3s that use different salts that cover the entire zone, it is - computationally infeasible to generate such a set. See Section 8.2 - for further discussion. - - - -Laurie, et al. Expires August 5, 2006 [Page 8] - -Internet-Draft nsec3 February 2006 - - - The salt value SHOULD be changed from time to time - this is to - prevent the use of a precomputed dictionary to reduce the cost of - enumeration. - -3.1.6. The Next Hashed Ownername Field - - The Next Hashed Ownername field contains the next hashed ownername in - hash order. That is, given the set of all hashed owernames, the Next - Hashed Ownername contains the hash value that immediately follows the - owner hash value for the given NSEC3 record. The value of the Next - Hashed Ownername Field in the last NSEC3 record in the zone is the - same as the ownername of the first NSEC3 RR in the zone in hash - order. - - Hashed ownernames of glue RRsets MUST NOT be listed in the Next - Hashed Ownername unless at least one authoritative RRset exists at - the same ownername. Hashed ownernames of delegation NS RRsets MUST - be listed if the Opt-In bit is clear. - - Note that the Next Hashed Ownername field is not encoded, unlike the - NSEC3 RR's ownername. It is the unmodified binary hash value. It - does not include the name of the containing zone. - - The length of this field is the length of the hash value produced by - the hash function selected by the Hash Function field. - -3.1.7. The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC3 RR's original ownername. - - The Type bits for the NSEC3 RR and RRSIG RR MUST be set during - generation, and MUST be ignored during processing. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the window block's - bitmap, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC3 RR RDATA in increasing numerical - order. - - "|" denotes concatenation - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - - - -Laurie, et al. Expires August 5, 2006 [Page 9] - -Internet-Draft nsec3 February 2006 - - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC3 - RR's ownername. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC3 RR's ownername. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC3 RR's actual ownername. Trailing zero octets not specified MUST - be interpreted as zero octets. - -3.2. The NSEC3 RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Opt-In Flag Field is represented as an unsigned decimal integer. - The value is either 0 or 1. - - The Hash field is presented as a mnemonic of the hash or as an - unsigned decimal integer. The value has a maximum of 127. - - The Iterations field is presented as an unsigned decimal integer. - - The Salt Length field is not presented. - - The Salt field is represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is not allowed within the sequence. - The Salt Field is represented as "-" (without the quotes) when the - Salt Length field has value 0. - - The Next Hashed Ownername field is represented as a sequence of case- - insensitive base32 digits, without whitespace. - - The Type Bit Maps Field is represented as a sequence of RR type - - - -Laurie, et al. Expires August 5, 2006 [Page 10] - -Internet-Draft nsec3 February 2006 - - - mnemonics. When the mnemonic is not known, the TYPE representation - as described in RFC 3597 [12] (section 5) MUST be used. - - -4. Creating Additional NSEC3 RRs for Empty Non-Terminals - - In order to prove the non-existence of a record that might be covered - by a wildcard, it is necessary to prove the existence of its closest - encloser. A closest encloser might be an empty non-terminal. - - Additional NSEC3 RRs are generated for empty non-terminals. These - additional NSEC3 RRs are identical in format to NSEC3 RRs that cover - existing RRs in the zone except that their type-maps only indicated - the existence of an NSEC3 RRset and an RRSIG RRset. - - This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs - not appear at names that did not exist before the zone was signed. - [Comment.1] - - -5. Calculation of the Hash - - Define H(x) to be the hash of x using the hash function selected by - the NSEC3 record and || to indicate concatenation. Then define: - - IH(salt,x,0)=H(x || salt) - - IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 - - Then the calculated hash of an ownername is - IH(salt,ownername,iterations-1), where the ownername is the canonical - form. - - The canonical form of the ownername is the wire format of the - ownername where: - 1. The ownername is fully expanded (no DNS name compression) and - fully qualified; - 2. All uppercase US-ASCII letters are replaced by the corresponding - lowercase US-ASCII letters; - 3. If the ownername is a wildcard name, the ownername is in its - original unexpanded form, including the "*" label (no wildcard - substitution); - This form is as defined in section 6.2 of RFC 4034 ([4]). - - -6. Including NSEC3 RRs in a Zone - - Each ownername within the zone that owns authoritative RRsets MUST - - - -Laurie, et al. Expires August 5, 2006 [Page 11] - -Internet-Draft nsec3 February 2006 - - - have a corresponding NSEC3 RR. Ownernames that correspond to - unsigned delegations MAY have a corresponding NSEC3 RR, however, if - there is not, there MUST be a covering NSEC3 RR with the Opt-In flag - set to 1. Other non-authoritative RRs are not included in the set of - NSEC3 RRs. - - Each empty non-terminal MUST have an NSEC3 record. - - The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - The type bitmap of every NSEC3 resource record in a signed zone MUST - indicate the presence of both the NSEC3 RR type itself and its - corresponding RRSIG RR type. - - The following steps describe the proper construction of NSEC3 - records. [Comment.2] - 1. For each unique original ownername in the zone, add an NSEC3 - RRset. If Opt-In is being used, ownernames of unsigned - delegations may be excluded, but must be considered for empty- - non-terminals. The ownername of the NSEC3 RR is the hashed - equivalent of the original owner name, prepended to the zone - name. The Next Hashed Ownername field is left blank for the - moment. If Opt-In is being used, set the Opt-In bit to one. - 2. For each RRset at the original owner name, set the corresponding - bit in the type bit map. - 3. If the difference in number of labels between the apex and the - original ownername is greater then 1, additional NSEC3s need to - be added for every empty non-terminal between the apex and the - original ownername. This process may generate NSEC3 RRs with - duplicate hashed ownernames. - 4. Sort the set of NSEC3 RRs into hash order. Hash order is the - ascending numerical order of the non-encoded hash values. - 5. Combine NSEC3 RRs with identical hashed ownernames by replacing - with a single NSEC3 RR with the type map consisting of the union - of the types represented by the set of NSEC3 RRs. - 6. In each NSEC3 RR, insert the Next Hashed Ownername by using the - value of the next NSEC3 RR in hash order. The Next Hashed - Ownername of the last NSEC3 in the zone contains the value of the - hashed ownername of the first NSEC3 in the hash order. - - -7. Responding to NSEC3 Queries - - Since NSEC3 ownernames are not represented in the NSEC3 chain like - other zone ownernames, direct queries for NSEC3 ownernames present a - special case. - - - - -Laurie, et al. Expires August 5, 2006 [Page 12] - -Internet-Draft nsec3 February 2006 - - - The special case arises when the following are all true: - o The QNAME equals an existing NSEC3 ownername, and - o There are no other record types that exist at QNAME, and - o The QTYPE does not equal NSEC3. - These conditions describe a particular case: the answer should be a - NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to - include in the authority section. - - However, the NSEC3 RRset with ownername equal to QNAME is able to - prove its own existence. Thus, when answering this query, the - authoritative server MUST include the NSEC3 RRset whose ownername - equals QNAME. This RRset proves that QNAME is an existing name with - types NSEC3 and RRSIG. The authoritative server MUST also include - the NSEC3 RRset that covers the hash of QNAME. This RRset proves - that no other types exist. - - When validating a NOERROR/NODATA response, validators MUST check for - a NSEC3 RRset with ownername equals to QNAME, and MUST accept that - (validated) NSEC3 RRset as proof that QNAME exists. The validator - MUST also check for an NSEC3 RRset that covers the hash of QNAME as - proof that QTYPE doesn't exist. - - Other cases where the QNAME equals an existing NSEC3 ownername may be - answered normally. - - -8. Special Considerations - - The following paragraphs clarify specific behaviour explain special - considerations for implementations. - -8.1. Proving Nonexistence - - If a wildcard resource record appears in a zone, its asterisk label - is treated as a literal symbol and is treated in the same way as any - other ownername for purposes of generating NSEC3 RRs. RFC 4035 [5] - describes the impact of wildcards on authenticated denial of - existence. - - In order to prove there exist no RRs for a domain, as well as no - source of synthesis, an RR must be shown for the closest encloser, - and non-existence must be shown for all closer labels and for the - wildcard at the closest encloser. - - This can be done as follows. If the QNAME in the query is - omega.alfa.beta.example, and the closest encloser is beta.example - (the nearest ancestor to omega.alfa.beta.example), then the server - should return an NSEC3 that demonstrates the nonexistence of - - - -Laurie, et al. Expires August 5, 2006 [Page 13] - -Internet-Draft nsec3 February 2006 - - - alfa.beta.example, an NSEC3 that demonstrates the nonexistence of - *.beta.example, and an NSEC3 that demonstrates the existence of - beta.example. This takes between one and three NSEC3 records, since - a single record can, by chance, prove more than one of these facts. - - When a verifier checks this response, then the existence of - beta.example together with the non-existence of alfa.beta.example - proves that the closest encloser is indeed beta.example. The non- - existence of *.beta.example shows that there is no wildcard at the - closest encloser, and so no source of synthesis for - omega.alfa.beta.example. These two facts are sufficient to satisfy - the resolver that the QNAME cannot be resolved. - - In practice, since the NSEC3 owner and next names are hashed, if the - server responds with an NSEC3 for beta.example, the resolver will - have to try successively longer names, starting with example, moving - to beta.example, alfa.beta.example, and so on, until one of them - hashes to a value that matches the interval (but not the ownername - nor next owner name) of one of the returned NSEC3s (this name will be - alfa.beta.example). Once it has done this, it knows the closest - encloser (i.e. beta.example), and can then easily check the other two - required proofs. - - Note that it is not possible for one of the shorter names tried by - the resolver to be denied by one of the returned NSEC3s, since, by - definition, all these names exist and so cannot appear within the - range covered by an NSEC3. Note, however, that the first name that - the resolver tries MUST be the apex of the zone, since names above - the apex could be denied by one of the returned NSEC3s. - -8.2. Salting - - Augmenting original ownernames with salt before hashing increases the - cost of a dictionary of pre-generated hash-values. For every bit of - salt, the cost of a precomputed dictionary doubles (because there - must be an entry for each word combined with each possible salt - value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of - salt, multiplying the cost by 2^2040. This means that an attacker - must, in practice, recompute the dictionary each time the salt is - changed. - - There MUST be at least one complete set of NSEC3s for the zone using - the same salt value. - - The salt SHOULD be changed periodically to prevent precomputation - using a single salt. It is RECOMMENDED that the salt be changed for - every resigning. - - - - -Laurie, et al. Expires August 5, 2006 [Page 14] - -Internet-Draft nsec3 February 2006 - - - Note that this could cause a resolver to see records with different - salt values for the same zone. This is harmless, since each record - stands alone (that is, it denies the set of ownernames whose hashes, - using the salt in the NSEC3 record, fall between the two hashes in - the NSEC3 record) - it is only the server that needs a complete set - of NSEC3 records with the same salt in order to be able to answer - every possible query. - - There is no prohibition with having NSEC3 with different salts within - the same zone. However, in order for authoritative servers to be - able to consistently find covering NSEC3 RRs, the authoritative - server MUST choose a single set of parameters (algorithm, salt, and - iterations) to use when selecting NSEC3s. In the absence of any - other metadata, the server does this by using the parameters from the - zone apex NSEC3, recognizable by the presence of the SOA bit in the - type map. If there is more than one NSEC3 record that meets this - description, then the server may arbitrarily choose one. Because of - this, if there is a zone apex NSEC3 RR within a zone, it MUST be part - of a complete NSEC3 set. Conversely, if there exists an incomplete - set of NSEC3 RRs using the same parameters within a zone, there MUST - NOT be an NSEC3 RR using those parameters with the SOA bit set. - -8.3. Iterations - - Setting the number of iterations used allows the zone owner to choose - the cost of computing a hash, and so the cost of generating a - dictionary. Note that this is distinct from the effect of salt, - which prevents the use of a single precomputed dictionary for all - time. - - Obviously the number of iterations also affects the zone owner's cost - of signing the zone as well as the verifiers cost of verifying the - zone. We therefore impose an upper limit on the number of - iterations. We base this on the number of iterations that - approximately doubles the cost of signing the zone. - - A zone owner MUST NOT use a value higher than shown in the table - below for iterations. A resolver MAY treat a response with a higher - value as bogus. - - +--------------+------------+ - | RSA Key Size | Iterations | - +--------------+------------+ - | 1024 | 3,000 | - | 2048 | 20,000 | - | 4096 | 150,000 | - +--------------+------------+ - - - - -Laurie, et al. Expires August 5, 2006 [Page 15] - -Internet-Draft nsec3 February 2006 - - - +--------------+------------+ - | DSA Key Size | Iterations | - +--------------+------------+ - | 1024 | 1,500 | - | 2048 | 5,000 | - +--------------+------------+ - - This table is based on 150,000 SHA-1's per second, 50 RSA signs per - second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1 - sign per second for 4096 bit keys, 100 DSA signs per second for 1024 - bit keys and 30 signs per second for 2048 bit keys. - - Note that since RSA verifications are 10-100 times faster than - signatures (depending on key size), in the case of RSA the legal - values of iterations can substantially increase the cost of - verification. - -8.4. Hash Collision - - Hash collisions occur when different messages have the same hash - value. The expected number of domain names needed to give a 1 in 2 - chance of a single collision is about 2^(n/2) for a hash of length n - bits (i.e. 2^80 for SHA-1). Though this probability is extremely - low, the following paragraphs deal with avoiding collisions and - assessing possible damage in the event of an attack using hash - collisions. - -8.4.1. Avoiding Hash Collisions during generation - - During generation of NSEC3 RRs, hash values are supposedly unique. - In the (academic) case of a collision occurring, an alternative salt - MUST be chosen and all hash values MUST be regenerated. - -8.4.2. Second Preimage Requirement Analysis - - A cryptographic hash function has a second-preimage resistance - property. The second-preimage resistance property means that it is - computationally infeasible to find another message with the same hash - value as a given message, i.e. given preimage X, to find a second - preimage X' != X such that hash(X) = hash(X'). The work factor for - finding a second preimage is of the order of 2^160 for SHA-1. To - mount an attack using an existing NSEC3 RR, an adversary needs to - find a second preimage. - - Assuming an adversary is capable of mounting such an extreme attack, - the actual damage is that a response message can be generated which - claims that a certain QNAME (i.e. the second pre-image) does exist, - while in reality QNAME does not exist (a false positive), which will - - - -Laurie, et al. Expires August 5, 2006 [Page 16] - -Internet-Draft nsec3 February 2006 - - - either cause a security aware resolver to re-query for the non- - existent name, or to fail the initial query. Note that the adversary - can't mount this attack on an existing name but only on a name that - the adversary can't choose and does not yet exist. - -8.4.3. Possible Hash Value Truncation Method - - The previous sections outlined the low probability and low impact of - a second-preimage attack. When impact and probability are low, while - space in a DNS message is costly, truncation is tempting. Truncation - might be considered to allow for shorter ownernames and rdata for - hashed labels. In general, if a cryptographic hash is truncated to n - bits, then the expected number of domains required to give a 1 in 2 - probability of a single collision is approximately 2^(n/2) and the - work factor to produce a second preimage is 2^n. - - An extreme hash value truncation would be truncating to the shortest - possible unique label value. This would be unwise, since the work - factor to produce second preimages would then approximate the size of - the zone (sketch of proof: if the zone has k entries, then the length - of the names when truncated down to uniqueness should be proportional - to log_2(k). Since the work factor to produce a second pre-image is - 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where - C is some constant), i.e. C'k - a work factor of k). - - Though the mentioned truncation can be maximized to a certain - extreme, the probability of collision increases exponentially for - every truncated bit. Given the low impact of hash value collisions - and limited space in DNS messages, the balance between truncation - profit and collision damage may be determined by local policy. Of - course, the size of the corresponding RRSIG RR is not reduced, so - truncation is of limited benefit. - - Truncation could be signaled simply by reducing the length of the - first label in the ownername. Note that there would have to be a - corresponding reduction in the length of the Next Hashed Ownername - field. - -8.4.4. Server Response to a Run-time Collision - - In the astronomically unlikely event that a server is unable to prove - nonexistence because the hash of the name that does not exist - collides with a name that does exist, the server is obviously broken, - and should, therefore, return a response with an RCODE of 2 (server - failure). - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 17] - -Internet-Draft nsec3 February 2006 - - -8.4.5. Parameters that Cover the Zone - - Secondary servers (and perhaps other entities) need to reliably - determine which NSEC3 parameters (that is, hash, salt and iterations) - are present at every hashed ownername, in order to be able to choose - an appropriate set of NSEC3 records for negative responses. This is - indicated by the parameters at the apex: any set of parameters that - is used in an NSEC3 record whose original ownername is the apex of - the zone MUST be present throughout the zone. - - A method to determine which NSEC3 in a complete chain corresponds to - the apex is to look for a NSEC3 RRset which has the SOA bit set in - the RDATA bit type maps field. - - -9. Performance Considerations - - Iterated hashes impose a performance penalty on both authoritative - servers and resolvers. Therefore, the number of iterations should be - carefully chosen. In particular it should be noted that a high value - for iterations gives an attacker a very good denial of service - attack, since the attacker need not bother to verify the results of - their queries, and hence has no performance penalty of his own. - - On the other hand, nameservers with low query rates and limited - bandwidth are already subject to a bandwidth based denial of service - attack, since responses are typically an order of magnitude larger - than queries, and hence these servers may choose a high value of - iterations in order to increase the difficulty of offline attempts to - enumerate their namespace without significantly increasing their - vulnerability to denial of service attacks. - - -10. IANA Considerations - - IANA needs to allocate a RR type code for NSEC3 from the standard RR - type space (type XXX requested). IANA needs to open a new registry - for the NSEC3 Hash Functions. The range for this registry is 0-127. - Defined types are: - - 0 is reserved. - 1 is SHA-1 ([13]). - 127 is experimental. - - -11. Security Considerations - - The NSEC3 records are still susceptible to dictionary attacks (i.e. - - - -Laurie, et al. Expires August 5, 2006 [Page 18] - -Internet-Draft nsec3 February 2006 - - - the attacker retrieves all the NSEC3 records, then calculates the - hashes of all likely domain names, comparing against the hashes found - in the NSEC3 records, and thus enumerating the zone). These are - substantially more expensive than enumerating the original NSEC - records would have been, and in any case, such an attack could also - be used directly against the name server itself by performing queries - for all likely names, though this would obviously be more detectable. - The expense of this off-line attack can be chosen by setting the - number of iterations in the NSEC3 RR. - - Domains are also susceptible to a precalculated dictionary attack - - that is, a list of hashes for all likely names is computed once, then - NSEC3 is scanned periodically and compared against the precomputed - hashes. This attack is prevented by changing the salt on a regular - basis. - - Walking the NSEC3 RRs will reveal the total number of records in the - zone, and also what types they are. This could be mitigated by - adding dummy entries, but certainly an upper limit can always be - found. - - Hash collisions may occur. If they do, it will be impossible to - prove the non-existence of the colliding domain - however, this is - fantastically unlikely, and, in any case, DNSSEC already relies on - SHA-1 to not collide. - - Responses to queries where QNAME equals an NSEC3 ownername that has - no other types may be undetectably changed from a NOERROR/NODATA - response to a NAME ERROR response. - - The Opt-In Flag (O) allows for unsigned names, in the form of - delegations to unsigned subzones, to exist within an otherwise signed - zone. All unsigned names are, by definition, insecure, and their - validity or existence cannot by cryptographically proven. - - In general: - Records with unsigned names (whether existing or not) suffer from - the same vulnerabilities as records in an unsigned zone. These - vulnerabilities are described in more detail in [16] (note in - particular sections 2.3, "Name Games" and 2.6, "Authenticated - Denial"). - Records with signed names have the same security whether or not - Opt-In is used. - - Note that with or without Opt-In, an insecure delegation may be - undetectably altered by an attacker. Because of this, the primary - difference in security when using Opt-In is the loss of the ability - to prove the existence or nonexistence of an insecure delegation - - - -Laurie, et al. Expires August 5, 2006 [Page 19] - -Internet-Draft nsec3 February 2006 - - - within the span of an Opt-In NSEC3 record. - - In particular, this means that a malicious entity may be able to - insert or delete records with unsigned names. These records are - normally NS records, but this also includes signed wildcard - expansions (while the wildcard record itself is signed, its expanded - name is an unsigned name). - - For example, if a resolver received the following response from the - example zone above: - - Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A - - RCODE=NOERROR - - Answer Section: - - Authority Section: - DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. - EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ - RRSIG DNSKEY - abcd... RRSIG NSEC3 ... - - Additional Section: - - The resolver would have no choice but to accept that the referral to - NS.FORGED. is valid. If a wildcard existed that would have been - expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could - have undetectably removed it and replaced it with the forged - delegation. - - Note that being able to add a delegation is functionally equivalent - to being able to add any record type: an attacker merely has to forge - a delegation to nameserver under his/her control and place whatever - records needed at the subzone apex. - - While in particular cases, this issue may not present a significant - security problem, in general it should not be lightly dismissed. - Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. - In particular, zone signing tools SHOULD NOT default to using Opt-In, - and MAY choose to not support Opt-In at all. - - -12. References - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 20] - -Internet-Draft nsec3 February 2006 - - -12.1. Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - - [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [7] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [10] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [11] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain - Name System (DNS) IANA Considerations", BCP 42, RFC 2929, - September 2000. - - [12] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - [13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", - RFC 3174, September 2001. - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 21] - -Internet-Draft nsec3 February 2006 - - -12.2. Informative References - - [14] Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)", - draft-vixie-dnssec-ter-01 (work in progress), June 2004. - - [15] Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data - Encodings.", draft-josefsson-rfc3548bis-00 (work in progress), - October 2005. - - [16] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name - System (DNS)", RFC 3833, August 2004. - -Editorial Comments - - [Comment.1] Although, strictly speaking, the names *did* exist. - - [Comment.2] Note that this method makes it impossible to detect - (extremely unlikely) hash collisions. - - -Appendix A. Example Zone - - This is a zone showing its NSEC3 records. They can also be used as - test vectors for the hash algorithm. - - The data in the example zone is currently broken, as it uses a - different base32 alphabet. This shall be fixed in the next release. - - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 ) - 3600 RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l - m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d - 1SH5r/wfjuCg+g== ) - 3600 MX 1 xx.example. - - - -Laurie, et al. Expires August 5, 2006 [Page 22] - -Internet-Draft nsec3 February 2006 - - - 3600 RRSIG MX 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l - NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU - S/o/g5C8VM6ftQ== ) - 3600 DNSKEY 257 3 5 ( - AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX - cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 - zsYKWJ7BvR2894hX - ) ; Key ID = 21960 - 3600 DNSKEY 256 3 5 ( - AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU - 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL - ExXT48OGGdbfIme5 - ) ; Key ID = 62699 - 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z - xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx - mTkunTYzqWJrmQ== ) - 3600 RRSIG DNSKEY 5 1 3600 20050712112304 ( - 20050612112304 21960 example. - SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk - ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik - 3w7ZY2UWyYIvpw== ) - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 ( - deadbeaf - 7nomf47k3vlidh4vxahhpp47l3tgv7a2 - NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5 - Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ - sb7KfbaUo/vzAg== ) - 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 ( - deadbeaf - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb - MX NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA - ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo - MEFQmc/gEuxojA== ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B - 766A6A4837206C ) - 3600 RRSIG DS 5 2 3600 20050712112304 ( - - - -Laurie, et al. Expires August 5, 2006 [Page 23] - -Internet-Draft nsec3 February 2006 - - - 20050612112304 62699 example. - QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn - cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 - 0kx7rGKTc3RQDA== ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU - 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq - ZXW5S+1VjMZYzQ== ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk - tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg - VGNmbgPnqDVPiA== ) - 3600 AAAA 2001:db8:0:0:0:0:f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV - ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns - l5/UqLCJJ9BDMg== ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 ( - deadbeaf - gmnfcccja7wkax3iv26bs75myptje3qk - MX DNSKEY NS SOA NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D - C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R - MOiKMSHozVebqw== ) - gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 ( - deadbeaf - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6 - DS NS NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/ - ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW - OwQBGbOegrW/Zw== ) - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 ( - deadbeaf - - - -Laurie, et al. Expires August 5, 2006 [Page 24] - -Internet-Draft nsec3 February 2006 - - - kcll7fqfnisuhfekckeeqnmbbd4maanu - NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V - IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK - 94Zbq3k8lgdpZA== ) - kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 ( - deadbeaf - n42hbhnjj333xdxeybycax5ufvntux5d - MX NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA - IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx - TOLtc5jPrkL4zQ== ) - n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 ( - deadbeaf - nimwfwcnbeoodmsc6npv3vuaagaevxxu - A NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy - 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj - xFPFGRIW3wKnrA== ) - nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 ( - deadbeaf - vhgwr2qgykdkf4m6iv6vkagbxozphazr - HINFO A AAAA NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx - z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG - jL33Wm1p07TBdw== ) - ns1.example. 3600 A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb - BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr - nWWLepz1PjjShQ== ) - ns2.example. 3600 A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 - P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz - AkeTJu3J3auUiA== ) - vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 ( - deadbeaf - - - -Laurie, et al. Expires August 5, 2006 [Page 25] - -Internet-Draft nsec3 February 2006 - - - wbyijvpnyj33pcpi3i44ecnibnaj7eiw - HINFO A AAAA NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W - kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M - 5SNSHIyfpfsi6A== ) - *.w.example. 3600 MX 1 ai.example. - 3600 RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF - xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ - gQlgxEwhvQDEaQ== ) - x.w.example. 3600 MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w - lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP - U9VazOa1KEIq1w== ) - x.y.w.example. 3600 MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20050712112304 ( - 20050612112304 62699 example. - aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7 - uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF - 9VrQvJjwbllAfA== ) - wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 ( - deadbeaf - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui - A NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN - ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd - oorBv4xkb0flXw== ) - xx.example. 3600 A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 - tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj - cxwCXWj82GVGdw== ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q - OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk - KMf4DgNBDj+dIQ== ) - 3600 AAAA 2001:db8:0:0:0:0:f00:baaa - 3600 RRSIG AAAA 5 2 3600 20050712112304 ( - - - -Laurie, et al. Expires August 5, 2006 [Page 26] - -Internet-Draft nsec3 February 2006 - - - 20050612112304 62699 example. - rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo - w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy - rzKKwb8J04/ILw== ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 ( - deadbeaf - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd - MX NSEC3 RRSIG ) - 3600 RRSIG NSEC3 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt - 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny - OcFlrPGPMm48/A== ) - - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1. answer - - A successful query to an authoritative server. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 27] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w - lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP - U9VazOa1KEIq1w== ) - - ;; Authority - example. 3600 IN NS ns1.example. - example. 3600 IN NS ns2.example. - example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l - m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d - 1SH5r/wfjuCg+g== ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9 - tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj - cxwCXWj82GVGdw== ) - xx.example. 3600 IN AAAA 2001:db8::f00:baaa - xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo - w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy - rzKKwb8J04/ILw== ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb - BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr - nWWLepz1PjjShQ== ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3 - P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz - AkeTJu3J3auUiA== ) - - - - -Laurie, et al. Expires August 5, 2006 [Page 28] - -Internet-Draft nsec3 February 2006 - - - The query returned an MX RRset for "x.w.example". The corresponding - RRSIG RR indicates that the MX RRset was signed by an "example" - DNSKEY with algorithm 5 and key tag 62699. The resolver needs the - corresponding DNSKEY RR in order to authenticate this answer. The - discussion below describes how a resolver might obtain this DNSKEY - RR. - - The RRSIG RR indicates the original TTL of the MX RRset was 3600, - and, for the purpose of authentication, the current TTL is replaced - by 3600. The RRSIG RR's labels field value of 3 indicates that the - answer was not the result of wildcard expansion. The "x.w.example" - MX RRset is placed in canonical form, and, assuming the current time - falls between the signature inception and expiration dates, the - signature is authenticated. - -B.1.1. Authenticating the Example DNSKEY RRset - - This example shows the logical authentication process that starts - from a configured root DNSKEY RRset (or DS RRset) and moves down the - tree to authenticate the desired "example" DNSKEY RRset. Note that - the logical order is presented for clarity. An implementation may - choose to construct the authentication as referrals are received or - to construct the authentication chain only after all RRsets have been - obtained, or in any other combination it sees fit. The example here - demonstrates only the logical process and does not dictate any - implementation rules. - - We assume the resolver starts with a configured DNSKEY RRset for the - root zone (or a configured DS RRset for the root zone). The resolver - checks whether this configured DNSKEY RRset is present in the root - DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY - RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the - root DNSKEY RRset, and whether the signature lifetime is valid. If - all these conditions are met, all keys in the DNSKEY RRset are - considered authenticated. The resolver then uses one (or more) of - the root DNSKEY RRs to authenticate the "example" DS RRset. Note - that the resolver may have to query the root zone to obtain the root - DNSKEY RRset or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - matching "example" DNSKEY is found, the resolver checks whether this - DNSKEY RR has signed the "example" DNSKEY RRset and the signature - lifetime is valid. If these conditions are met, all keys in the - "example" DNSKEY RRset are considered authenticated. - - Finally, the resolver checks that some DNSKEY RR in the "example" - - - -Laurie, et al. Expires August 5, 2006 [Page 29] - -Internet-Draft nsec3 February 2006 - - - DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This - DNSKEY is used to authenticate the RRSIG included in the response. - If multiple "example" DNSKEY RRs match this algorithm and key tag, - then each DNSKEY RR is tried, and the answer is authenticated if any - of the matching DNSKEY RRs validate the signature as described above. - -B.2. Name Error - - An authoritative name error. The NSEC3 RRs prove that the name does - not exist and that no covering wildcard exists. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 30] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - a.c.x.w.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb - MX NSEC3 RRSIG ) - 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA - ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo - MEFQmc/gEuxojA== ) - nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - vhgwr2qgykdkf4m6iv6vkagbxozphazr - HINFO A AAAA NSEC3 RRSIG ) - nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx - z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG - jL33Wm1p07TBdw== ) - ;; Additional - ;; (empty) - - The query returned two NSEC3 RRs that prove that the requested data - does not exist and no wildcard applies. The negative reply is - authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are - authenticated in a manner identical to that of the MX RRset discussed - - - -Laurie, et al. Expires August 5, 2006 [Page 31] - -Internet-Draft nsec3 February 2006 - - - above. At least one of the owner names of the NSEC3 RRs will match - the closest encloser. At least one of the NSEC3 RRs prove that there - exists no longer name. At least one of the NSEC3 RRs prove that - there exists no wildcard RRsets that should have been expanded. The - closest encloser can be found by hashing the apex ownername (The SOA - RR's ownername, or the ownername of the DNSKEY RRset referred by an - RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and - if that fails, continue by adding labels. In other words, the - resolver first hashes example, checks for a matching NSEC3 ownername, - then hashes w.example, checks, and finally hashes w.x.example and - checks. - - In the above example, the name 'x.w.example' hashes to - '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might - be the closest encloser. To prove that 'c.x.w.example' and - '*.x.w.example' do not exists, these names are hashed to respectively - 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and - 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that - these hashed ownernames do not exists, since the names are within the - given intervals. - -B.3. No Data Error - - A "no data" response. The NSEC3 RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 32] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui - A NSEC3 RRSIG ) - wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN - ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd - oorBv4xkb0flXw== ) - ;; Additional - ;; (empty) - - The query returned an NSEC3 RR that proves that the requested name - exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"), - but the requested RR type does not exist (type MX is absent in the - type code list of the NSEC RR). The negative reply is authenticated - by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner - identical to that of the MX RRset discussed above. - -B.3.1. No Data Error, Empty Non-Terminal - - A "no data" response because of an empty non-terminal. The NSEC3 RR - proves that the name exists and that the requested RR type does not. - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 33] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - y.w.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - kcll7fqfnisuhfekckeeqnmbbd4maanu - NSEC3 RRSIG ) - jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V - IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK - 94Zbq3k8lgdpZA== ) - - The query returned an NSEC3 RR that proves that the requested name - exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"), - but the requested RR type does not exist (Type A is absent in the - type-bit-maps of the NSEC3 RR). The negative reply is authenticated - by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner - identical to that of the MX RRset discussed above. Note that, unlike - generic empty non terminal proof using NSECs, this is identical to - proving a No Data Error. This example is solely mentioned to be - complete. - -B.4. Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - - - -Laurie, et al. Expires August 5, 2006 [Page 34] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR DO RCODE=0 - ;; - - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 IN DS 58470 5 1 ( - 3079F1593EBAD6DC121E202A8B766A6A4837 - 206C ) - a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn - cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2 - 0kx7rGKTc3RQDA== ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - The query returned a referral to the signed "a.example." zone. The - DS RR is authenticated in a manner identical to that of the MX RRset - discussed above. This DS RR is used to authenticate the "a.example" - DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks whether - this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether - the signature lifetime is valid. If all these conditions are met, - all keys in the "a.example" DNSKEY RRset are considered - authenticated. - -B.5. Referral to Unsigned Zone using the Opt-In Flag - - The NSEC3 RR proves that nothing for this delegation was signed in - the parent zone. There is no proof that the delegation exists - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 35] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 ( - deadbeaf - n42hbhnjj333xdxeybycax5ufvntux5d - MX NSEC3 RRSIG ) - kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA - IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx - TOLtc5jPrkL4zQ== ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - The query returned a referral to the unsigned "b.example." zone. The - NSEC3 proves that no authentication leads from "example" to - "b.example", since the hash of "b.example" - ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and - the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a - manner identical to that of the MX RRset discussed above. - -B.6. Wildcard Expansion - - A successful query that was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC3 RR proves that - no closer match exists in the zone. - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 36] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 ( - 20050612112304 62699 example. - sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF - xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ - gQlgxEwhvQDEaQ== ) - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 IN RRSIG NS 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l - m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d - 1SH5r/wfjuCg+g== ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd - MX NSEC3 RRSIG ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt - 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny - OcFlrPGPMm48/A== ) - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU - 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq - ZXW5S+1VjMZYzQ== ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 ( - 20050612112304 62699 example. - PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV - ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns - l5/UqLCJJ9BDMg== ) - - The query returned an answer that was produced as a result of - wildcard expansion. The answer section contains a wildcard RRset - expanded as it would be in a traditional DNS response, and the - corresponding RRSIG indicates that the expanded wildcard MX RRset was - - - -Laurie, et al. Expires August 5, 2006 [Page 37] - -Internet-Draft nsec3 February 2006 - - - signed by an "example" DNSKEY with algorithm 5 and key tag 62699. - The RRSIG indicates that the original TTL of the MX RRset was 3600, - and, for the purpose of authentication, the current TTL is replaced - by 3600. The RRSIG labels field value of 2 indicates that the answer - is the result of wildcard expansion, as the "a.z.w.example" name - contains 4 labels. The name "a.z.w.example" is replaced by - "*.w.example", the MX RRset is placed in canonical form, and, - assuming that the current time falls between the signature inception - and expiration dates, the signature is authenticated. - - The NSEC3 proves that no closer match (exact or closer wildcard) - could have been used to answer this query, and the NSEC3 RR must also - be authenticated before the answer is considered valid. - -B.7. Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC3 RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 38] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - 5pe7ctl7pfs2cilroy5dcofx4rcnlypd - MX NSEC3 RRSIG ) - zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt - 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny - OcFlrPGPMm48/A== ) - ;; Additional - ;; (empty) - - The query returned NSEC3 RRs that prove that the requested data does - not exist and no wildcard applies. The negative reply is - authenticated by verifying both NSEC3 RRs. - -B.8. DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query that was mistakenly sent to - a name server for the child zone. - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 39] - -Internet-Draft nsec3 February 2006 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 ( - 20050612112304 62699 example. - RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK - mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g - qYIt90txzE/4+g== ) - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 ( - deadbeaf - gmnfcccja7wkax3iv26bs75myptje3qk - MX DNSKEY NS SOA NSEC3 RRSIG ) - dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 ( - 5 2 3600 20050712112304 - 20050612112304 62699 example. - VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D - C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R - MOiKMSHozVebqw== ) - - ;; Additional - ;; (empty) - - The query returned NSEC RRs that shows the requested was answered by - a child server ("example" server). The NSEC RR indicates the - presence of an SOA RR, showing that the answer is from the child . - Queries for the "example" DS RRset should be sent to the parent - servers ("root" servers). - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 40] - -Internet-Draft nsec3 February 2006 - - -Authors' Addresses - - Ben Laurie - Nominet - 17 Perryn Road - London W3 7LR - England - - Phone: +44 (20) 8735 0686 - Email: ben@algroup.co.uk - - - Geoffrey Sisson - Nominet - - - Roy Arends - Nominet - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Laurie, et al. Expires August 5, 2006 [Page 41] - -Internet-Draft nsec3 February 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Laurie, et al. Expires August 5, 2006 [Page 42] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt deleted file mode 100644 index 90d1a06..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt +++ /dev/null @@ -1,840 +0,0 @@ - - - -Network Working Group R. Austein -Internet-Draft ISC -Expires: July 15, 2006 January 11, 2006 - - - DNS Name Server Identifier Option (NSID) - draft-ietf-dnsext-nsid-01 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 15, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. While existing ad-hoc - mechanism allow an operator to send follow-up queries when it is - necessary to debug such a configuration, the only completely reliable - way to obtain the identity of the name server which responded is to - have the name server include this information in the response itself. - This note defines a protocol extension to support this functionality. - - - -Austein Expires July 15, 2006 [Page 1] - -Internet-Draft DNS NSID January 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4 - 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 - 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8 - 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8 - 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 2] - -Internet-Draft DNS NSID January 2006 - - -1. Introduction - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. - - Existing ad-hoc mechanisms allow an operator to send follow-up - queries when it is necessary to debug such a configuration, but there - are situations in which this is not a totally satisfactory solution, - since anycast routing may have changed, or the server pool in - question may be behind some kind of extremely dynamic load balancing - hardware. Thus, while these ad-hoc mechanisms are certainly better - than nothing (and have the advantage of already being deployed), a - better solution seems desirable. - - Given that a DNS query is an idempotent operation with no retained - state, it would appear that the only completely reliable way to - obtain the identity of the name server which responded to a - particular query is to have that name server include identifying - information in the response itself. This note defines a protocol - enhancement to achieve this. - -1.1. Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 3] - -Internet-Draft DNS NSID January 2006 - - -2. Protocol - - This note uses an EDNS [RFC2671] option to signal the resolver's - desire for information identifying the name server and to hold the - name server's response, if any. - -2.1. Resolver Behavior - - A resolver signals its desire for information identifying a name - server by sending an empty NSID option (Section 2.3) in an EDNS OPT - pseudo-RR in the query message. - - The resolver MUST NOT include any NSID payload data in the query - message. - - The semantics of an NSID request are not transitive. That is: the - presence of an NSID option in a query is a request that the name - server which receives the query identify itself. If the name server - side of a recursive name server receives an NSID request, the client - is asking the recursive name server to identify itself; if the - resolver side of the recursive name server wishes to receive - identifying information, it is free to add NSID requests in its own - queries, but that is a separate matter. - -2.2. Name Server Behavior - - A name server which understands the NSID option and chooses to honor - a particular NSID request responds by including identifying - information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR - in the response message. - - The name server MUST ignore any NSID payload data that might be - present in the query message. - - The NSID option is not transitive. A name server MUST NOT send an - NSID option back to a resolver which did not request it. In - particular, while a recursive name server may choose to add an NSID - option when sending a query, this has no effect on the presence or - absence of the NSID option in the recursive name server's response to - the original client. - - As stated in Section 2.1, this mechanism is not restricted to - authoritative name servers; the semantics are intended to be equally - applicable to recursive name servers. - -2.3. The NSID Option - - The OPTION-CODE for the NSID option is [TBD]. - - - -Austein Expires July 15, 2006 [Page 4] - -Internet-Draft DNS NSID January 2006 - - - The OPTION-DATA for the NSID option is an opaque byte string the - semantics of which are deliberately left outside the protocol. See - Section 3.1 for discussion. - -2.4. Presentation Format - - User interfaces MUST read and write the content of the NSID option as - a sequence of hexadecimal digits, two digits per payload octet. - - The NSID payload is binary data. Any comparison between NSID - payloads MUST be a comparison of the raw binary data. Copy - operations MUST NOT assume that the raw NSID payload is null- - terminated. Any resemblance between raw NSID payload data and any - form of text is purely a convenience, and does not change the - underlying nature of the payload data. - - See Section 3.3 for discussion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 5] - -Internet-Draft DNS NSID January 2006 - - -3. Discussion - - This section discusses certain aspects of the protocol and explains - considerations that led to the chosen design. - -3.1. The NSID Payload - - The syntax and semantics of the content of the NSID option is - deliberately left outside the scope of this specification. This - section describe some of the kinds of data that server administrators - might choose to provide as the content of the NSID option, and - explains the reasoning behind choosing a simple opaque byte string. - - There are several possibilities for the payload of the NSID option: - - o It could be the "real" name of the specific name server within the - name server pool. - - o It could be the "real" IP address (IPv4 or IPv6) of the name - server within the name server pool. - - o It could be some sort of pseudo-random number generated in a - predictable fashion somehow using the server's IP address or name - as a seed value. - - o It could be some sort of probabilisticly unique identifier - initially derived from some sort of random number generator then - preserved across reboots of the name server. - - o It could be some sort of dynamicly generated identifier so that - only the name server operator could tell whether or not any two - queries had been answered by the same server. - - o It could be a blob of signed data, with a corresponding key which - might (or might not) be available via DNS lookups. - - o It could be a blob of encrypted data, the key for which could be - restricted to parties with a need to know (in the opinion of the - server operator). - - o It could be an arbitrary string of octets chosen at the discretion - of the name server operator. - - Each of these options has advantages and disadvantages: - - o Using the "real" name is simple, but the name server may not have - a "real" name. - - - - -Austein Expires July 15, 2006 [Page 6] - -Internet-Draft DNS NSID January 2006 - - - o Using the "real" address is also simple, and the name server - almost certainly does have at least one non-anycast IP address for - maintenance operations, but the operator of the name server may - not be willing to divulge its non-anycast address. - - o Given that one common reason for using anycast DNS techniques is - an attempt to harden a critical name server against denial of - service attacks, some name server operators are likely to want an - identifier other than the "real" name or "real" address of the - name server instance. - - o Using a hash or pseudo-random number can provide a fixed length - value that the resolver can use to tell two name servers apart - without necessarily being able to tell where either one of them - "really" is, but makes debugging more difficult if one happens to - be in a friendly open environment. Furthermore, hashing might not - add much value, since a hash based on an IPv4 address still only - involves a 32-bit search space, and DNS names used for servers - that operators might have to debug at 4am tend not to be very - random. - - o Probabilisticly unique identifiers have similar properties to - hashed identifiers, but (given a sufficiently good random number - generator) are immune to the search space issues. However, the - strength of this approach is also its weakness: there is no - algorithmic transformation by which even the server operator can - associate name server instances with identifiers while debugging, - which might be annoying. This approach also requires the name - server instance to preserve the probabilisticly unique identifier - across reboots, but this does not appear to be a serious - restriction, since authoritative nameservers almost always have - some form of nonvolatile storage in any case, and in the rare case - of a name server that does not have any way to store such an - identifier, nothing terrible will happen if the name server just - generates a new identifier every time it reboots. - - o Using an arbitrary octet string gives name server operators yet - another thing to configure, or mis-configure, or forget to - configure. Having all the nodes in an anycast name server - constellation identify themselves as "My Name Server" would not be - particularly useful. - - Given all of the issues listed above, there does not appear to be a - single solution that will meet all needs. Section 2.3 therefore - defines the NSID payload to be an opaque byte string and leaves the - choice up to the implementor and name server operator. The following - guidelines may be useful to implementors and server operators: - - - - -Austein Expires July 15, 2006 [Page 7] - -Internet-Draft DNS NSID January 2006 - - - o Operators for whom divulging the unicast address is an issue could - use the raw binary representation of a probabilisticly unique - random number. This should probably be the default implementation - behavior. - - o Operators for whom divulging the unicast address is not an issue - could just use the raw binary representation of a unicast address - for simplicity. This should only be done via an explicit - configuration choice by the operator. - - o Operators who really need or want the ability to set the NSID - payload to an arbitrary value could do so, but this should only be - done via an explicit configuration choice by the operator. - - This approach appears to provide enough information for useful - debugging without unintentionally leaking the maintenance addresses - of anycast name servers to nogoodniks, while also allowing name - server operators who do not find such leakage threatening to provide - more information at their own discretion. - -3.2. NSID Is Not Transitive - - As specified in Section 2.1 and Section 2.2, the NSID option is not - transitive. This is strictly a hop-by-hop mechanism. - - Most of the discussion of name server identification to date has - focused on identifying authoritative name servers, since the best - known cases of anycast name servers are a subset of the name servers - for the root zone. However, given that anycast DNS techniques are - also applicable to recursive name servers, the mechanism may also be - useful with recursive name servers. The hop-by-hop semantics support - this. - - While there might be some utility in having a transitive variant of - this mechanism (so that, for example, a stub resolver could ask a - recursive server to tell it which authoritative name server provided - a particular answer to the recursive name server), the semantics of - such a variant would be more complicated, and are left for future - work. - -3.3. User Interface Issues - - Given the range of possible payload contents described in - Section 3.1, it is not possible to define a single presentation - format for the NSID payload that is efficient, convenient, - unambiguous, and aesthetically pleasing. In particular, while it is - tempting to use a presentation format that uses some form of textual - strings, attempting to support this would significantly complicate - - - -Austein Expires July 15, 2006 [Page 8] - -Internet-Draft DNS NSID January 2006 - - - what's intended to be a very simple debugging mechanism. - - In some cases the content of the NSID payload may be binary data - meaningful only to the name server operator, and may not be - meaningful to the user or application, but the user or application - must be able to capture the entire content anyway in order for it to - be useful. Thus, the presentation format must support arbitrary - binary data. - - In cases where the name server operator derives the NSID payload from - textual data, a textual form such as US-ASCII or UTF-8 strings might - at first glance seem easier for a user to deal with. There are, - however, a number of complex issues involving internationalized text - which, if fully addressed here, would require a set of rules - significantly longer than the rest of this specification. See - [RFC2277] for an overview of some of these issues. - - It is much more important for the NSID payload data to be passed - unambiguously from server administrator to user and back again than - it is for the payload data data to be pretty while in transit. In - particular, it's critical that it be straightforward for a user to - cut and paste an exact copy of the NSID payload output by a debugging - tool into other formats such as email messages or web forms without - distortion. Hexadecimal strings, while ugly, are also robust. - -3.4. Truncation - - In some cases, adding the NSID option to a response message may - trigger message truncation. This specification does not change the - rules for DNS message truncation in any way, but implementors will - need to pay attention to this issue. - - Including the NSID option in a response is always optional, so this - specification never requires name servers to truncate response - messages. - - By definition, a resolver that requests NSID responses also supports - EDNS, so a resolver that requests NSID responses can also use the - "sender's UDP payload size" field of the OPT pseudo-RR to signal a - receive buffer size large enough to make truncation unlikely. - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 9] - -Internet-Draft DNS NSID January 2006 - - -4. IANA Considerations - - This mechanism requires allocation of one ENDS option code for the - NSID option (Section 2.3). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 10] - -Internet-Draft DNS NSID January 2006 - - -5. Security Considerations - - This document describes a channel signaling mechanism, intended - primarily for debugging. Channel signaling mechanisms are outside - the scope of DNSSEC per se. Applications that require integrity - protection for the data being signaled will need to use a channel - security mechanism such as TSIG [RFC2845]. - - Section 3.1 discusses a number of different kinds of information that - a name server operator might choose to provide as the value of the - NSID option. Some of these kinds of information are security - sensitive in some environments. This specification deliberately - leaves the syntax and semantics of the NSID option content up to the - implementation and the name server operator. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 11] - -Internet-Draft DNS NSID January 2006 - - -6. Acknowledgements - - Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve - Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg, - Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and - Suzanne Woolf. Apologies to anyone inadvertently omitted from the - above list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 12] - -Internet-Draft DNS NSID January 2006 - - -7. References - -7.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - -7.2. Informative References - - [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and - Languages", RFC 2277, BCP 18, January 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 13] - -Internet-Draft DNS NSID January 2006 - - -Author's Address - - Rob Austein - ISC - 950 Charter Street - Redwood City, CA 94063 - USA - - Email: sra@isc.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein Expires July 15, 2006 [Page 14] - -Internet-Draft DNS NSID January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Austein Expires July 15, 2006 [Page 15] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt deleted file mode 100644 index 5b6d655..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt +++ /dev/null @@ -1,464 +0,0 @@ - -INTERNET-DRAFT DSA Information in the DNS -OBSOLETES: RFC 2536 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: January 2006 July 2005 - - - DSA Keying and Signature Information in the DNS - --- ------ --- --------- ----------- -- --- --- - <draft-ietf-dnsext-rfc2536bis-dsa-06.txt> - Donald E. Eastlake 3rd - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Distribution of this document is unlimited. Comments should be sent - to the 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 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 of encoding US Government Digital Signature - Algorithm keying and signature information for use in the Domain Name - System is specified. - - -Copyright Notice - - Copyright (C) The Internet Society 2005. All Rights Reserved. - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DSA Information in the DNS - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................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 and Disclaimer...................................5 - - Normative References.......................................7 - Informative References.....................................7 - - Authors 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 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. - - -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -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 - - -Authors 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 January 2006. - - Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt deleted file mode 100644 index 2ec9dbe..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt +++ /dev/null @@ -1,840 +0,0 @@ - - - -Network Working Group S. Josefsson -Internet-Draft August 30, 2005 -Expires: March 3, 2006 - - - Storing Certificates in the Domain Name System (DNS) - draft-ietf-dnsext-rfc2538bis-04 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 3, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - Cryptographic public keys are frequently published and their - authenticity demonstrated by certificates. A CERT resource record - (RR) is defined so that such certificates and related certificate - revocation lists can be stored in the Domain Name System (DNS). - - This document obsoletes RFC 2538. - - - - - - -Josefsson Expires March 3, 2006 [Page 1] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 - 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4 - 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5 - 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 - 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 - 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 - 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9 - 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 - 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9 - 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10 - 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 - Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires March 3, 2006 [Page 2] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -1. Introduction - - Public keys are frequently published in the form of a certificate and - their authenticity is commonly demonstrated by certificates and - related certificate revocation lists (CRLs). A certificate is a - binding, through a cryptographic digital signature, of a public key, - a validity interval and/or conditions, and identity, authorization, - or other information. A certificate revocation list is a list of - certificates that are revoked, and incidental information, all signed - by the signer (issuer) of the revoked certificates. Examples are - X.509 certificates/CRLs in the X.500 directory system or OpenPGP - certificates/revocations used by OpenPGP software. - - Section 2 below specifies a CERT resource record (RR) for the storage - of certificates in the Domain Name System [1] [2]. - - Section 3 discusses appropriate owner names for CERT RRs. - - Sections 4, 5, and 6 below cover performance, IANA, and security - considerations, respectively. - - 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 [3]. - - -2. The CERT Resource Record - - The CERT resource record (RR) has the structure given below. Its RR - type code is 37. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | type | key tag | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | algorithm | / - +---------------+ certificate or CRL / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - The type field is the certificate type as defined in section 2.1 - below. - - The key tag field is the 16 bit value computed for the key embedded - in the certificate, using the RRSIG Key Tag algorithm described in - Appendix B of [10]. This field is used as an efficiency measure to - pick which CERT RRs may be applicable to a particular key. The key - - - -Josefsson Expires March 3, 2006 [Page 3] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - tag can be calculated for the key in question and then only CERT RRs - with the same key tag need be examined. However, the key must always - be transformed to the format it would have as the public key portion - of a DNSKEY RR before the key tag is computed. This is only possible - if the key is applicable to an algorithm (and limits such as key size - limits) defined for DNS security. If it is not, the algorithm field - MUST BE zero and the tag field is meaningless and SHOULD BE zero. - - The algorithm field has the same meaning as the algorithm field in - DNSKEY and RRSIG RRs [10], except that a zero algorithm field - indicates the algorithm is unknown to a secure DNS, which may simply - be the result of the algorithm not having been standardized for - DNSSEC. - -2.1. Certificate Type Values - - The following values are defined or reserved: - - Value Mnemonic Certificate Type - ----- -------- ---------------- - 0 reserved - 1 PKIX X.509 as per PKIX - 2 SPKI SPKI certificate - 3 PGP OpenPGP packet - 4 IPKIX The URL of an X.509 data object - 5 ISPKI The URL of an SPKI certificate - 6 IPGP The URL of an OpenPGP packet - 7-252 available for IANA assignment - 253 URI URI private - 254 OID OID private - 255-65534 available for IANA assignment - 65535 reserved - - The PKIX type is reserved to indicate an X.509 certificate conforming - to the profile being defined by the IETF PKIX working group. The - certificate section will start with a one-byte unsigned OID length - and then an X.500 OID indicating the nature of the remainder of the - certificate section (see 2.3 below). (NOTE: X.509 certificates do - not include their X.500 directory type designating OID as a prefix.) - - The SPKI type is reserved to indicate the SPKI certificate format - [13], for use when the SPKI documents are moved from experimental - status. - - The PGP type indicates an OpenPGP packet as described in [6] and its - extensions and successors. Two uses are to transfer public key - material and revocation signatures. The data is binary, and MUST NOT - be encoded into an ASCII armor. An implementation SHOULD process - - - -Josefsson Expires March 3, 2006 [Page 4] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - transferable public keys as described in section 10.1 of [6], but it - MAY handle additional OpenPGP packets. - - The IPKIX, ISPKI and IPGP types indicate a URL which will serve the - content that would have been in the "certificate, CRL or URL" field - of the corresponding (PKIX, SPKI or PGP) packet types. These types - are known as "indirect". These packet types MUST be used when the - content is too large to fit in the CERT RR, and MAY be used at the - implementer's discretion. They SHOULD NOT be used where the entire - UDP packet would have fit in 512 bytes. - - The URI private type indicates a certificate format defined by an - absolute URI. The certificate portion of the CERT RR MUST begin with - a null terminated URI [5] and the data after the null is the private - format certificate itself. The URI SHOULD be such that a retrieval - from it will lead to documentation on the format of the certificate. - Recognition of private certificate types need not be based on URI - equality but can use various forms of pattern matching so that, for - example, subtype or version information can also be encoded into the - URI. - - The OID private type indicates a private format certificate specified - by an ISO OID prefix. The certificate section will start with a one- - byte unsigned OID length and then a BER encoded OID indicating the - nature of the remainder of the certificate section. This can be an - X.509 certificate format or some other format. X.509 certificates - that conform to the IETF PKIX profile SHOULD be indicated by the PKIX - type, not the OID private type. Recognition of private certificate - types need not be based on OID equality but can use various forms of - pattern matching such as OID prefix. - -2.2. Text Representation of CERT RRs - - The RDATA portion of a CERT RR has the type field as an unsigned - decimal integer or as a mnemonic symbol as listed in section 2.1 - above. - - The key tag field is represented as an unsigned decimal integer. - - The algorithm field is represented as an unsigned decimal integer or - a mnemonic symbol as listed in [10]. - - The certificate / CRL portion is represented in base 64 [14] and may - be divided up into any number of white space separated substrings, - down to single base 64 digits, which are concatenated to obtain the - full signature. These substrings can span lines using the standard - parenthesis. - - - - -Josefsson Expires March 3, 2006 [Page 5] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - Note that the certificate / CRL portion may have internal sub-fields, - but these do not appear in the master file representation. For - example, with type 254, there will be an OID size, an OID, and then - the certificate / CRL proper. But only a single logical base 64 - string will appear in the text representation. - -2.3. X.509 OIDs - - OIDs have been defined in connection with the X.500 directory for - user certificates, certification authority certificates, revocations - of certification authority, and revocations of user certificates. - The following table lists the OIDs, their BER encoding, and their - length-prefixed hex format for use in CERT RRs: - - id-at-userCertificate - = { joint-iso-ccitt(2) ds(5) at(4) 36 } - == 0x 03 55 04 24 - id-at-cACertificate - = { joint-iso-ccitt(2) ds(5) at(4) 37 } - == 0x 03 55 04 25 - id-at-authorityRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 38 } - == 0x 03 55 04 26 - id-at-certificateRevocationList - = { joint-iso-ccitt(2) ds(5) at(4) 39 } - == 0x 03 55 04 27 - - -3. Appropriate Owner Names for CERT RRs - - It is recommended that certificate CERT RRs be stored under a domain - name related to their subject, i.e., the name of the entity intended - to control the private key corresponding to the public key being - certified. It is recommended that certificate revocation list CERT - RRs be stored under a domain name related to their issuer. - - Following some of the guidelines below may result in the use in DNS - names of characters that require DNS quoting which is to use a - backslash followed by the octal representation of the ASCII code for - the character (e.g., \000 for NULL). - - The choice of name under which CERT RRs are stored is important to - clients that perform CERT queries. In some situations, the clients - may not know all information about the CERT RR object it wishes to - retrieve. For example, a client may not know the subject name of an - X.509 certificate, or the e-mail address of the owner of an OpenPGP - key. Further, the client might only know the hostname of a service - that uses X.509 certificates or the Key ID of an OpenPGP key. - - - -Josefsson Expires March 3, 2006 [Page 6] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - Therefore, two owner name guidelines are defined: content-based owner - names and purpose-based owner names. A content-based owner name is - derived from the content of the CERT RR data; for example, the - Subject field in an X.509 certificate or the User ID field in OpenPGP - keys. A purpose-based owner name is a name that a client retrieving - CERT RRs MUST already know; for example, the host name of an X.509 - protected service or the Key ID of an OpenPGP key. The content-based - and purpose-based owner name MAY be the same; for example, when a - client looks up a key based on the From: address of an incoming - e-mail. - - Implementations SHOULD use the purpose-based owner name guidelines - described in this document, and MAY use CNAMEs of content-based owner - names (or other names), pointing to the purpose-based owner name. - -3.1. Content-based X.509 CERT RR Names - - Some X.509 versions permit multiple names to be associated with - subjects and issuers under "Subject Alternate Name" and "Issuer - Alternate Name". For example, X.509v3 has such Alternate Names with - an ASN.1 specification as follows: - - GeneralName ::= CHOICE { - otherName [0] INSTANCE OF OTHER-NAME, - rfc822Name [1] IA5String, - dNSName [2] IA5String, - x400Address [3] EXPLICIT OR-ADDRESS.&Type, - directoryName [4] EXPLICIT Name, - ediPartyName [5] EDIPartyName, - uniformResourceIdentifier [6] IA5String, - iPAddress [7] OCTET STRING, - registeredID [8] OBJECT IDENTIFIER - } - - The recommended locations of CERT storage are as follows, in priority - order: - 1. If a domain name is included in the identification in the - certificate or CRL, that should be used. - 2. If a domain name is not included but an IP address is included, - then the translation of that IP address into the appropriate - inverse domain name should be used. - 3. If neither of the above is used, but a URI containing a domain - name is present, that domain name should be used. - 4. If none of the above is included but a character string name is - included, then it should be treated as described for OpenPGP - names below. - - - - - -Josefsson Expires March 3, 2006 [Page 7] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - 5. If none of the above apply, then the distinguished name (DN) - should be mapped into a domain name as specified in [4]. - - Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/ - DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a) - string "John (the Man) Doe", (b) domain name john-doe.com, and (c) - uri <https://www.secure.john-doe.com:8080/>. The storage locations - recommended, in priority order, would be - 1. john-doe.com, - 2. www.secure.john-doe.com, and - 3. Doe.com.xy. - - Example 2: An X.509v3 certificate is issued to /CN=James Hacker/ - L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) - domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and - (c) string "James Hacker <hacker@mail.widget.foo.example>". The - storage locations recommended, in priority order, would be - 1. widget.foo.example, - 2. 201.13.251.10.in-addr.arpa, and - 3. hacker.mail.widget.foo.example. - -3.2. Purpose-based X.509 CERT RR Names - - Due to the difficulty for clients that do not already possess a - certificate to reconstruct the content-based owner name, purpose- - based owner names are recommended in this section. Recommendations - for purpose-based owner names vary per scenario. The following table - summarizes the purpose-based X.509 CERT RR owner name guidelines for - use with S/MIME [16], SSL/TLS [11], and IPSEC [12]: - - Scenario Owner name - ------------------ ---------------------------------------------- - S/MIME Certificate Standard translation of an RFC 2822 email - address. Example: An S/MIME certificate for - "postmaster@example.org" will use a standard - hostname translation of the owner name, - "postmaster.example.org". - - TLS Certificate Hostname of the TLS server. - - IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4 - or IPv6 addresses, the fully qualified domain - name in the appropriate reverse domain. - - An alternate approach for IPSEC is to store raw public keys [15]. - - - - - - -Josefsson Expires March 3, 2006 [Page 8] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -3.3. Content-based OpenPGP CERT RR Names - - OpenPGP signed keys (certificates) use a general character string - User ID [6]. However, it is recommended by OpenPGP that such names - include the RFC 2822 [8] email address of the party, as in "Leslie - Example <Leslie@host.example>". If such a format is used, the CERT - should be under the standard translation of the email address into a - domain name, which would be leslie.host.example in this case. If no - RFC 2822 name can be extracted from the string name, no specific - domain name is recommended. - - If a user has more than one email address, the CNAME type can be used - to reduce the amount of data stored in the DNS. Example: - - $ORIGIN example.org. - smith IN CERT PGP 0 0 <OpenPGP binary> - john.smith IN CNAME smith - js IN CNAME smith - -3.4. Purpose-based OpenPGP CERT RR Names - - Applications that receive an OpenPGP packet containing encrypted or - signed data but do not know the email address of the sender will have - difficulties constructing the correct owner name and cannot use the - content-based owner name guidelines. However, these clients commonly - know the key fingerprint or the Key ID. The key ID is found in - OpenPGP packets, and the key fingerprint is commonly found in - auxilliary data that may be available. In this case, use of an owner - name identical to the key fingerprint and the key ID expressed in - hexadecimal [14] is recommended. Example: - - $ORIGIN example.org. - 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... - F835EDA21E94B565716F IN CERT PGP ... - B565716F IN CERT PGP ... - - If the same key material is stored for several owner names, the use - of CNAME may be used to avoid data duplication. Note that CNAME is - not always applicable, because it maps one owner name to the other - for all purposes, which may be sub-optimal when two keys with the - same Key ID are stored. - -3.5. Owner names for IPKIX, ISPKI, and IPGP - - These types are stored under the same owner names, both purpose- and - content-based, as the PKIX, SPKI and PGP types. - - - - - -Josefsson Expires March 3, 2006 [Page 9] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -4. Performance Considerations - - Current Domain Name System (DNS) implementations are optimized for - small transfers, typically not more than 512 bytes including - overhead. While larger transfers will perform correctly and work is - underway to make larger transfers more efficient, it is still - advisable at this time to make every reasonable effort to minimize - the size of certificates stored within the DNS. Steps that can be - taken may include using the fewest possible optional or extension - fields and using short field values for necessary variable length - fields. - - The RDATA field in the DNS protocol may only hold data of size 65535 - octets (64kb) or less. This means that each CERT RR MUST NOT contain - more than 64kb of payload, even if the corresponding certificate or - certificate revocation list is larger. This document addresses this - by defining "indirect" data types for each normal type. - - -5. Contributors - - The majority of this document is copied verbatim from RFC 2538, by - Donald Eastlake 3rd and Olafur Gudmundsson. - - -6. Acknowledgements - - Thanks to David Shaw and Michael Graff for their contributions to - earlier works that motivated, and served as inspiration for, this - document. - - This document was improved by suggestions and comments from Olivier - Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason - Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is - incomplete. We apologize to anyone we left out. - - -7. Security Considerations - - By definition, certificates contain their own authenticating - signature. Thus, it is reasonable to store certificates in non- - secure DNS zones or to retrieve certificates from DNS with DNS - security checking not implemented or deferred for efficiency. The - results MAY be trusted if the certificate chain is verified back to a - known trusted key and this conforms with the user's security policy. - - Alternatively, if certificates are retrieved from a secure DNS zone - with DNS security checking enabled and are verified by DNS security, - - - -Josefsson Expires March 3, 2006 [Page 10] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - the key within the retrieved certificate MAY be trusted without - verifying the certificate chain if this conforms with the user's - security policy. - - If an organization chooses to issue certificates for it's employees, - placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC) - is in use, it is possible for someone to enumerate all employees of - the organization. This is usually not considered desirable, for the - same reason enterprise phone listings are not often publicly - published and are even mark confidential. - - When the URI type is used, it should be understood that it introduces - an additional indirection that may allow for a new attack vector. - One method to secure that indirection is to include a hash of the - certificate in the URI itself. - - CERT RRs are not used by DNSSEC [9], so there are no security - considerations related to CERT RRs and securing the DNS itself. - - If DNSSEC is used, then the non-existence of a CERT RR and, - consequently, certificates or revocation lists can be securely - asserted. Without DNSSEC, this is not possible. - - -8. IANA Considerations - - Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can - only be assigned by an IETF standards action [7]. This document - assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate - types 0x0100 through 0xFEFF are assigned through IETF Consensus [7] - based on RFC documentation of the certificate type. The availability - of private types under 0x00FD and 0x00FE should satisfy most - requirements for proprietary or private types. - - The CERT RR reuses the DNS Security Algorithm Numbers registry. In - particular, the CERT RR requires that algorithm number 0 remain - reserved, as described in Section 2. The IANA is directed to - reference the CERT RR as a user of this registry and value 0, in - particular. - - -9. Changes since RFC 2538 - - 1. Editorial changes to conform with new document requirements, - including splitting reference section into two parts and - updating the references to point at latest versions, and to add - some additional references. - - - - -Josefsson Expires March 3, 2006 [Page 11] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - 2. Improve terminology. For example replace "PGP" with "OpenPGP", - to align with RFC 2440. - 3. In section 2.1, clarify that OpenPGP public key data are binary, - not the ASCII armored format, and reference 10.1 in RFC 2440 on - how to deal with OpenPGP keys, and acknowledge that - implementations may handle additional packet types. - 4. Clarify that integers in the representation format are decimal. - 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis - terminology. Improve reference for Key Tag Algorithm - calculations. - 6. Add examples that suggest use of CNAME to reduce bandwidth. - 7. In section 3, appended the last paragraphs that discuss - "content-based" vs "purpose-based" owner names. Add section 3.2 - for purpose-based X.509 CERT owner names, and section 3.4 for - purpose-based OpenPGP CERT owner names. - 8. Added size considerations. - 9. The SPKI types has been reserved, until RFC 2692/2693 is moved - from the experimental status. - 10. Added indirect types IPKIX, ISPKI, and IPGP. - - -Appendix A. Copying conditions - - Regarding the portion of this document that was written by Simon - Josefsson ("the author", for the remainder of this section), the - author makes no guarantees and is not responsible for any damage - resulting from its use. The author grants irrevocable permission to - anyone to use, modify, and distribute it in any way that does not - diminish the rights of anyone else to use, modify, and distribute it, - provided that redistributed derivative works do not contain - misleading author or version information. Derivative works need not - be licensed under similar terms. - - -10. References - -10.1. Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, - - - -Josefsson Expires March 3, 2006 [Page 12] - -Internet-Draft Storing Certificates in the DNS August 2005 - - - "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247, - January 1998. - - [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifiers (URI): Generic Syntax", RFC 2396, - August 1998. - - [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, - "OpenPGP Message Format", RFC 2440, November 1998. - - [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - - [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [10] 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 - - [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", - RFC 2246, January 1999. - - [12] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., - and T. Ylonen, "SPKI Certificate Theory", RFC 2693, - September 1999. - - [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - [15] Richardson, M., "A Method for Storing IPsec Keying Material in - DNS", RFC 4025, March 2005. - - [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions - (S/MIME) Version 3.1 Message Specification", RFC 3851, - July 2004. - - - - - - -Josefsson Expires March 3, 2006 [Page 13] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -Author's Address - - Simon Josefsson - - Email: simon@josefsson.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires March 3, 2006 [Page 14] - -Internet-Draft Storing Certificates in the DNS August 2005 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -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. - - - - -Josefsson Expires March 3, 2006 [Page 15] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt deleted file mode 100644 index 5e6cb1d..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt +++ /dev/null @@ -1,580 +0,0 @@ - -INTERNET-DRAFT Diffie-Hellman Information in the DNS -OBSOLETES: RFC 2539 Donald E. Eastlake 3rd - Motorola Laboratories -Expires: January 2006 July 2005 - - - - - Storage of Diffie-Hellman Keying Information in the DNS - ------- -- -------------- ------ ----------- -- --- --- - <draft-ietf-dnsext-rfc2539bis-dhk-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. - - 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 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 encoding Diffie-Hellman keys in the Domain - Name System is specified. - - - -Copyright - - Copyright (C) The Internet Society 2005. - - - -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 - Copyright..................................................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 and Disclaimer...................................5 - - Normative References.......................................7 - Informative Refences.......................................7 - - Author 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]. - - - -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 - key is the pair p and g, which must be the same for the parties, and - their individual X (or Y). - - For further information about Diffie-Hellman and precautions to take - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - - 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 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. - - -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT Diffie-Hellman Information in the DNS - - -Normative References - - [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June - 1999. - - [RFC 2434] - "Guidelines for Writing an IANA Considerations Section - in RFCs", T. Narten, H. Alvestrand, 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. - - - -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 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 January 2006. - - Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.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/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt deleted file mode 100644 index 0af13c6..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt +++ /dev/null @@ -1,755 +0,0 @@ - - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt deleted file mode 100644 index 9c73c68..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt +++ /dev/null @@ -1,1292 +0,0 @@ - - - - - -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/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt deleted file mode 100644 index a598826..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt +++ /dev/null @@ -1,1501 +0,0 @@ -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.230.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/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt deleted file mode 100644 index 7cb9063..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt +++ /dev/null @@ -1,730 +0,0 @@ - - - - -Network Working Group M. StJohns -Internet-Draft Nominum, Inc. -Expires: July 14, 2006 January 10, 2006 - - - Automated Updates of DNSSEC Trust Anchors - draft-ietf-dnsext-trustupdate-timers-02 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 14, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a means for automated, authenticated and - authorized updating of DNSSEC "trust anchors". The method provides - protection against single key compromise of a key in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor. - - This mechanism, if adopted, will require changes to resolver - management behavior (but not resolver resolution behavior), and the - - - -StJohns Expires July 14, 2006 [Page 1] - -Internet-Draft trustanchor-update January 2006 - - - addition of a single flag bit to the DNSKEY record. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3 - 1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 3 - 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5 - 2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6 - 2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6 - 2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6 - 2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6 - 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6 - 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6 - 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8 - 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9 - 5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9 - 5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9 - 5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9 - 5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10 - 7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10 - 7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11 - 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 - - - - - - - - - - - - - - -StJohns Expires July 14, 2006 [Page 2] - -Internet-Draft trustanchor-update January 2006 - - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the - community has come to the realization that there will not be one - signed name space, but rather islands of signed name space each - originating from specific points (i.e. 'trust points') in the DNS - tree. Each of those islands will be identified by the trust point - name, and validated by at least one associated public key. For the - purpose of this document we'll call the association of that name and - a particular key a 'trust anchor'. A particular trust point can have - more than one key designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties. (e.g. Consider an - unsigned ".COM".) Requiring the owner of the resolver to manually - manage this many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key replacement/ - rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g. multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1. Compliance Nomenclature - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, [RFC2119]. - -1.2. Changes since -00 - - Added the concept of timer triggered resolver queries to refresh the - - - -StJohns Expires July 14, 2006 [Page 3] - -Internet-Draft trustanchor-update January 2006 - - - resolvers view of the trust anchor key RRSet. - - Re-submitted expired draft as -01. Updated DNSSEC RFC References. - - Draft -02. Added the IANA Considerations section. Added text to - describe what happens if all trust anchors at a trust point are - deleted. - - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a new SEP key is added to a trust point - DNSKEY RRSet, and when that RRSet is validated by an existing trust - anchor, then the new key can be added to the set of trust anchors. - - There are some issues with this approach which need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example assuming a single key - compromise, an attacker could add a new key and revoke all the other - old keys. - -2.1. Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set which didn't - contain A. To fix this, we add a mechanism which requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a self- - signed RRSet and the key has the REVOKE bit (see Section 6 below) set - to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this - key as a trust anchor or for any other purposes except validating the - RRSIG over the DNSKEY RRSet specifically for the purpose of - validating the revocation. Unlike the 'Add' operation below, - revocation is immediate and permanent upon receipt of a valid - revocation at the resolver. - - N.B. A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent, or the fingerprint stored at a resolver - used to configure a trust point. [msj3] - - In the given example, the attacker could revoke B because it has - - - -StJohns Expires July 14, 2006 [Page 4] - -Internet-Draft trustanchor-update January 2006 - - - knowledge of B's private key, but could not revoke A. - -2.2. Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key - C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in the both - the attacker and owner being able to sign data in the zone and have - it accepted as valid by resolvers. - - To mitigate, but not completely solve, this problem, we add a hold- - down time to the addition of the trust anchor. When the resolver - sees a new SEP key in a validated trust point DNSKEY RRSet, the - resolver starts an acceptance timer, and remembers all the keys that - validated the RRSet. If the resolver ever sees the DNSKEY RRSet - without the new key but validly signed, it stops the acceptance - process and resets the acceptance timer. If all of the keys which - were originally used to validate this key are revoked prior to the - timer expiring, the resolver stops the acceptance process and resets - the timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold down time which contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explictly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g. using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3. Remove Hold-down - - A new key which has been seen by the resolver, but hasn't reached - it's add hold-down time, MAY be removed from the DNSKEY RRSet by the - - - -StJohns Expires July 14, 2006 [Page 5] - -Internet-Draft trustanchor-update January 2006 - - - zone owner. If the resolver sees a validated DNSKEY RRSet without - this key, it waits for the remove hold-down time and then, if the key - hasn't reappeared, SHOULD discard any information about the key. - -2.4. Active Refresh - - A resolver which has been configured for automatic update of keys - from a particular trust point MUST query that trust point (e.g. do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days or half the original TTL for the DNSKEY - RRSet or half the RRSIG expiration interval. The expiration interval - is the amount of time from when the RRSIG was last retrieved until - the expiration time in the RRSIG. - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day or 10% of the original TTL or 10% of the original - expiration interval. - -2.5. Resolver Parameters - -2.5.1. Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the TTL - of the first trust point DNSKEY RRSet which contained the key, - whichever is greater. This ensures that at least two validated - DNSKEY RRSets which contain the new key MUST be seen by the resolver - prior to the key's acceptance. - -2.5.2. Remove Hold-Down Time - - The remove hold-down time is 30 days. - -2.5.3. Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - - -3. Changes to DNSKEY RDATA Wire Format - - Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE' - flag. If this bit is set to '1', AND the resolver sees an - RRSIG(DNSKEY) signed by the associated key, then the resolver MUST - consider this key permanently invalid for all purposes except for - validing the revocation. - - - - - -StJohns Expires July 14, 2006 [Page 6] - -Internet-Draft trustanchor-update January 2006 - - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes that view - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - [msj1] This is the state of a trust point key as seen from the - resolver. The column on the left indicates the current state. The - header at the top shows the next state. The intersection of the two - shows the event that will cause the state to transition from the - current state to the next. - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - -4.1. Events - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust point - after its been present in the RRSet for at least 'add time'. - KeyPres The key has returned to the valid DNSKEY RRSet. - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - RemTime A revoked key has been missing from the trust point DNSKEY - RRSet for sufficient time to be removed from the trust set. - RevBit The key has appeared in the trust anchor DNSKEY RRSet with its - "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet - signed by this key. - - - - - -StJohns Expires July 14, 2006 [Page 7] - -Internet-Draft trustanchor-update January 2006 - - -4.2. States - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but hasn't yet been - seen at the resolver. - AddPend The key has been seen at the resolver, has its 'SEP' bit set, - and has been included in a validated DNSKEY RRSet. There is a - hold-down time for the key before it can be used as a trust - anchor. - Valid The key has been seen at the resolver and has been included in - all validated DNSKEY RRSets from the time it was first seen up - through the hold-down time. It is now valid for verifying RRSets - that arrive after the hold down time. Clarification: The DNSKEY - RRSet does not need to be continuously present at the resolver - (e.g. its TTL might expire). If the RRSet is seen, and is - validated (i.e. verifies against an existing trust anchor), this - key MUST be in the RRSet otherwise a 'KeyRem' event is triggered. - Missing This is an abnormal state. The key remains as a valid trust - point key, but was not seen at the resolver in the last validated - DNSKEY RRSet. This is an abnormal state because the zone operator - should be using the REVOKE bit prior to removal. [Discussion - item: Should a missing key be considered revoked after some period - of time?] - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains - this key with its REVOKE bit set to '1'. Once in this state, this - key MUST permanently be considered invalid as a trust anchor. - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed state - MUST NOT be considered a valid trust anchor. - -4.3. Trust Point Deletion - - A trust point which has all of its trust anchors revoked is - considered deleted and is treated as if the trust point was never - configured. If there are no superior trust points, data at and below - the deleted trust point are considered insecure. If there there ARE - superior trust points, data at and below the deleted trust point are - evaluated with respect to the superior trust point. - - -5. Scenarios - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - - - -StJohns Expires July 14, 2006 [Page 8] - -Internet-Draft trustanchor-update January 2006 - - - Since the stand-by key is not in active signing use, the associated - private key may (and SHOULD) be provided with additional protections - not normally available to a key that must be used frequently. E.g. - locked in a safe, split among many parties, etc. Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -5.1. Adding A Trust Anchor - - Assume an existing trust anchor key 'A'. - 1. Generate a new key pair. - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - 3. Add the DNSKEY to the RRSet. - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - 5. Wait a while. - -5.2. Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - 1. Set the revolcation bit on key 'A'. - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. - 'A' is now revoked. The operator SHOULD include the revoked 'A' in - the RRSet for at least the remove hold-down time, but then may remove - it from the DNSKEY RRSet. - -5.3. Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet.) - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator SHOULD include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -5.4. Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 5.3) - above assuming 'A' is the active key. - - - -StJohns Expires July 14, 2006 [Page 9] - -Internet-Draft trustanchor-update January 2006 - - -5.5. Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 5.3) above: - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' SHOULD continue to be - included in the RRSet for the remove hold-down time. - - -6. IANA Considerations - - The IANA will need to assign a bit in the DNSKEY flags field (see - section 4.3 of [RFC3755]) for the REVOKE bit. There are no other - IANA actions required. - - -7. Security Considerations - -7.1. Key Ownership vs Acceptance Policy - - The reader should note that, while the zone owner is responsible - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision - update trust anchor keys based on trust for a current trust anchor - key is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates outside the scope of this document. - -7.2. Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust - anchor key remains uncompromised. E.g. if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust anchor keys at a trust point are compromised. - - - - -StJohns Expires July 14, 2006 [Page 10] - -Internet-Draft trustanchor-update January 2006 - - -7.3. Dynamic Updates - - Allowing a resolver to update its trust anchor set based in-band key - information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - -8. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -Editorial Comments - - [msj1] msj: N.B. This table is preliminary and will be revised to - match implementation experience. For example, should there - be a state for "Add hold-down expired, but haven't seen the - new RRSet"? - - [msj2] msj: To be assigned. - - [msj3] msj: For discussion: What's the implementation guidance for - resolvers currently with respect to the non-assigned flag - bits? If they consider the flag bit when doing key matching - at the trust anchor, they won't be able to match. - - - - - - -StJohns Expires July 14, 2006 [Page 11] - -Internet-Draft trustanchor-update January 2006 - - -Author's Address - - Michael StJohns - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - USA - - Phone: +1-301-528-4729 - Email: Mike.StJohns@nominum.com - URI: www.nominum.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Expires July 14, 2006 [Page 12] - -Internet-Draft trustanchor-update January 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -StJohns Expires July 14, 2006 [Page 13] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt deleted file mode 100644 index 00476ae..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt +++ /dev/null @@ -1,522 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -UPDATES RFC 2845 Motorola Laboratories -Expires: July 2006 January 2006 - - HMAC SHA TSIG Algorithm Identifiers - ---- --- ---- --------- ----------- - <draft-ietf-dnsext-tsig-sha-06.txt> - - -Status of This Document - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - This draft is intended to be become a Proposed Standard RFC. - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - Use of the Domain Name System TSIG resource record requires - specification of a cryptographic message authentication code. - Currently identifiers have been specified only for the HMAC MD5 - (Message Digest) and GSS (Generic Security Service) TSIG algorithms. - This document standardizes identifiers and implementation - requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG - algorithms and standardizes how to specify and handle the truncation - of HMAC values in TSIG. - - -Copyright Notice - - Copyright (C) The Internet Society (2006). - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - - 2. Algorithms and Identifiers..............................4 - - 3. Specifying Truncation...................................5 - 3.1 Truncation Specification...............................5 - - 4. TSIG Truncation Policy and Error Provisions.............6 - - 5. IANA Considerations.....................................7 - 6. Security Considerations.................................7 - 7. Copyright and Disclaimer................................7 - - 8. Normative References....................................8 - 9. Informative References..................................8 - - Author's Address...........................................9 - Additional IPR Provisions..................................9 - Expiration and File Name...................................9 - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -1. Introduction - - [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to - authenticate DNS (Domain Name System [STD 13]) queries and responses. - This RR contains a domain name syntax data item which names the - authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG- - ALG.REG.INT name for authentication codes using the HMAC [RFC 2104] - algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also - registered "gss-tsig" as an identifier for TSIG authentication where - the cryptographic operations are delegated to the Generic Security - Service (GSS) [RFC 3645]. - - It should be noted that use of TSIG presumes prior agreement, between - the resolver and server involved, as to the algorithm and key to be - used. - - In Section 2, this document specifies additional names for TSIG - authentication algorithms based on US NIST SHA (United States, - National Institute of Science and Technology, Secure Hash Algorithm) - algorithms and HMAC and specifies the implementation requirements for - those algorithms. - - In Section 3, this document specifies the effect of inequality - between the normal output size of the specified hash function and the - length of MAC (message authentication code) data given in the TSIG - RR. In particular, it specifies that a shorter length field value - specifies truncation and a longer length field is an error. - - In Section 4, policy restrictions and implications related to - truncation and a new error code to indicate truncation shorter than - permitted by policy are described and specified. - - The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as - defined in [RFC 2119]. - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -2. Algorithms and Identifiers - - TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS - queries and responses. They are intended to be efficient symmetric - authentication codes based on a shared secret. (Asymmetric signatures - can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) - can be used for transaction signatures.) Used with a strong hash - function, HMAC [RFC 2104] provides a way to calculate such symmetric - authentication codes. The only specified HMAC based TSIG algorithm - identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. - - The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as - compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384, - and 512 bits, may be preferred in some cases particularly since - increasingly successful cryptanalytic attacks are being made on the - shorter hashes. - - Use of TSIG between a DNS resolver and server is by mutual agreement. - That agreement can include the support of additional algorithms and - criteria as to which algorithms and truncations are acceptable, - subject to the restriction and guidelines in Section 3 and 4 below. - Key agreement can be by the TKEY mechanism [RFC 2930] or other - mutually agreeable method. - - The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are - included in the table below for convenience. Implementations which - support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY - implement gss-tsig and the other algorithms listed below. - - Mandatory HMAC-MD5.SIG-ALG.REG.INT - Optional gss-tsig - Mandatory hmac-sha1 - Optional hmac-sha224 - Mandatory hmac-sha256 - Optional hamc-sha384 - Optional hmac-sha512 - - SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. - - - - - - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -3. Specifying Truncation - - When space is at a premium and the strength of the full length of an - HMAC is not needed, it is reasonable to truncate the HMAC output and - use the truncated value for authentication. HMAC SHA-1 truncated to - 96 bits is an option available in several IETF protocols including - IPSEC and TLS. - - The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the - size of the MAC field in octets. But [RFC 2845] does not specify what - to do if this MAC size differs from the length of the output of HMAC - for a particular hash function. Truncation is indicated by a MAC size - less than the HMAC size as specified below. - - - -3.1 Truncation Specification - - The specification for TSIG handling is changed as follows: - - 1. If "MAC size" field is greater than HMAC output length: - This case MUST NOT be generated and if received MUST cause the - packet to be dropped and RCODE 1 (FORMERR) to be returned. - - 2. If "MAC size" field equals HMAC output length: - Operation is as described in [RFC 2845] with the entire output - HMAC output present. - - 3. "MAC size" field is less than HMAC output length but greater than - that specified in case 4 below: - This is sent when the signer has truncated the HMAC output to - an allowable length, as described in RFC 2104, taking initial - octets and discarding trailing octets. TSIG truncation can only be - to an integral number of octets. On receipt of a packet with - truncation thus indicated, the locally calculated MAC is similarly - truncated and only the truncated values compared for - authentication. The request MAC used when calculating the TSIG MAC - for a reply is the truncated request MAC. - - 4. "MAC size" field is less than the larger of 10 (octets) and half - the length of the hash function in use: - With the exception of certain TSIG error messages described in - RFC 2845 section 3.2 where it is permitted that the MAC size be - zero, this case MUST NOT be generated and if received MUST cause - the packet to be dropped and RCODE 1 (FORMERR) to be returned. The - size limit for this case can also, for the hash functions - mentioned in this document, be stated as less than half the hash - function length for hash functions other than MD5 and less than 10 - octets for MD5. - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -4. TSIG Truncation Policy and Error Provisions - - Use of TSIG is by mutual agreement between a resolver and server. - Implicit in such "agreement" are criterion as to acceptable keys and - algorithms and, with the extensions in this document, truncations. - Note that it is common for implementations to bind the TSIG secret - key or keys that may be in place at a resolver and server to - particular algorithms. Thus such implementations only permit the use - of an algorithm if there is an associated key in place. Receipt of an - unknown, unimplemented, or disabled algorithm typically results in a - BADKEY error. - - Local policies MAY require the rejection of TSIGs even though they - use an algorithm for which implementation is mandatory. - - When a local policy permits acceptance of a TSIG with a particular - algorithm and a particular non-zero amount of truncation it SHOULD - also permit the use of that algorithm with lesser truncation (a - longer MAC) up to the full HMAC output. - - Regardless of a lower acceptable truncated MAC length specified by - local policy, a reply SHOULD be sent with a MAC at least as long as - that in the corresponding request unless the request specified a MAC - length longer than the HMAC output. - - Implementations permitting multiple acceptable algorithms and/or - truncations SHOULD permit this list to be ordered by presumed - strength and SHOULD allow different truncations for the same - algorithm to be treated as separate entities in this list. When so - implemented, policies SHOULD accept a presumed stronger algorithm and - truncation than the minimum strength required by the policy. - - If a TSIG is received with truncation which is permitted under - Section 3 above but the MAC is too short for the local policy in - force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -5. IANA Considerations - - This document, on approval for publication as a standards track RFC, - (1) registers the new TSIG algorithm identifiers listed in Section 2 - with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in - Section 4. [RFC 2845] - - - -6. Security Considerations - - For all of the message authentication code algorithms listed herein, - those producing longer values are believed to be stronger; however, - while there have been some arguments that mild truncation can - strengthen a MAC by reducing the information available to an - attacker, excessive truncation clearly weakens authentication by - reducing the number of bits an attacker has to try to break the - authentication by brute force [RFC 2104]. - - Significant progress has been made recently in cryptanalysis of hash - function of the type used herein, all of which ultimately derive from - the design of MD4. While the results so far should not effect HMAC, - the stronger SHA-1 and SHA-256 algorithms are being made mandatory - due to caution. - - See the Security Considerations section of [RFC 2845]. See also the - Security Considerations section of [RFC 2104] from which the limits - on truncation in this RFC were taken. - - - -7. Copyright and Disclaimer - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -8. Normative References - - [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US - Federal Information Processing Standard, with Change Notice 1, - February 2004. - - [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC - 1321, April 1992. - - [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February 1997. - - [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224", - September 2004, - - [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms - (SHA)", draft-eastlake-sha2-*.txt, work in progress. - - [STD 13] - Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - - -9. Informative References. - - [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS - (TKEY RR)", RFC 2930, September 2000. - - [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction - Signatures ( SIG(0)s )", RFC 2931, September 2000. - - [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, - J., and R. Hall, "Generic Security Service Algorithm for Secret Key - Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October - 2003. - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - - EMail: Donald.Eastlake@motorola.com - - - -Additional IPR Provisions - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology - described in this document or the extent to which any license - under such rights might or might not be available; nor does it - represent that it has made any independent effort to identify any - such rights. Information on the procedures with respect to - rights in RFC documents can be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention - any copyrights, patents or patent applications, or other - proprietary rights that may cover technology that may be required - to implement this standard. Please address the information to the - IETF at ietf-ipr@ietf.org. - - - -Expiration and File Name - - This draft expires in July 2006. - - Its file name is draft-ietf-dnsext-tsig-sha-06.txt - - - - - - - - -D. Eastlake 3rd [Page 9] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt deleted file mode 100644 index 9cf88a5..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt +++ /dev/null @@ -1,1063 +0,0 @@ -Internet-Draft dnsext-wcard January 9, 2006 - -DNSEXT Working Group E. Lewis -INTERNET DRAFT NeuStar -Expiration Date: July 9, 2006 January 9, 2006 -Updates RFC 1034, RFC 2672 - - The Role of Wildcards - in the Domain Name System - draft-ietf-dnsext-wcard-clarify-10.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that - any applicable patent or other IPR claims of which he or she is - aware have been or will be disclosed, and any of which he or she - becomes aware will be disclosed, in accordance with Section 6 of - BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on July 9, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This is an update to the wildcard definition of RFC 1034. The - interaction with wildcards and CNAME is changed, an error - condition removed, and the words defining some concepts central - to wildcards are changed. The overall goal is not to change - wildcards, but to refine the definition of RFC 1034. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 1] - -Internet-Draft dnsext-wcard January 9, 2006 - -Table of Contents - -1. Introduction . . . . . . . . . . . . . . . . 3 -1 1 Motivation 3 -1 2 The Original Definition 3 -1 3 Roadmap to This Document 4 -1 3 1 New Terms 4 -1.3.2 Changed Text 5 -1.3.3 Considerations with Special Types 5 -1.4 Standards Terminology 5 -2. Wildcard Syntax . . . . . . . . . . . . . . . 6 -2.1 Identifying a Wildcard 6 -2.1.1 Wild Card Domain Name and Asterisk Label 6 -2.1.2 Asterisks and Other Characters 6 -2.1.3 Non-terminal Wild Card Domain Names 6 -2.2 Existence Rules 7 -2.2.1 An Example 7 -2.2.2 Empty Non-terminals 9 -2.2.3 Yet Another Definition of Existence 10 -2.3 When is a Wild Card Domain Name Not Special 10 -3. Impact of a Wild Card Domain Name On a Response . . . . . 10 -3.1 Step 2 10 -3.2 Step 3 11 -3.3 Part 'c' 11 -3.3.1 Closest Encloser and the Source of Synthesis 12 -3.3.2 Closest Encloser and Source of Synthesis Examples 12 -3.3.3 Type Matching 13 -4. Considerations with Special Types . . . . . . . . . 13 -4.1 SOA RRSet at a Wild Card Domain Name 13 -4.2 NS RRSet at a Wild Card Domain Name 14 -4.2.1 Discarded Notions 14 -4.3 CNAME RRSet at a Wild Card Domain Name 15 -4.4 DNAME RRSet at a Wild Card Domain Name 15 -4.5 SRV RRSet at a Wild Card Domain Name 16 -4.6 DS RRSet at a Wild Card Domain Name 16 -4.7 NSEC RRSet at a Wild Card Domain Name 17 -4.8 RRSIG at a Wild Card Domain Name 17 -4.9 Empty Non-terminal Wild Card Domain Name 17 -5. Security Considerations . . . . . . . . . . . . . 17 -6. IANA Considerations . . . . . . . . . . . . . 17 -7. References . . . . . . . . . . . . . 17 -8. Editor . . . . . . . . . . . . . 18 -9. Others Contributing to the Document . . . . . . . . 18 -10. Trailing Boilerplate . . . . . . . . . . . . . 19 - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 2] - -Internet-Draft dnsext-wcard January 9, 2006 - -1. Introduction - - In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the - synthesis of answers from special resource records called - wildcards. The definition in RFC 1034 is incomplete and has - proven to be confusing. This document describes the wildcard - synthesis by adding to the discussion and making limited - modifications. Modifications are made to close inconsistencies - that have led to interoperability issues. This description - does not expand the service intended by the original definition. - - Staying within the spirit and style of the original documents, - this document avoids specifying rules for DNS implementations - regarding wildcards. The intention is to only describe what is - needed for interoperability, not restrict implementation choices. - In addition, consideration is given to minimize any backwards - compatibility issues with implementations that comply with RFC - 1034's definition. - - This document is focused on the concept of wildcards as defined - in RFC 1034. Nothing is implied regarding alternative means of - synthesizing resource record sets, nor are alternatives discussed. - -1.1 Motivation - - Many DNS implementations diverge, in different ways, from the - original definition of wildcards. Although there is clearly a - need to clarify the original documents in light of this alone, - the impetus for this document lay in the engineering of the DNS - security extensions [RFC4033]. With an unclear definition of - wildcards the design of authenticated denial became entangled. - - This document is intended to limit its changes, documenting only - those based on implementation experience, and to remain as close - to the original document as possible. To reinforce that this - document is meant to clarify and adjust and not redefine wildcards, - relevant sections of RFC 1034 are repeated verbatim to facilitate - comparison of the old and new text. - -1.2 The Original Definition - - The definition of the wildcard concept is comprised by the - documentation of the algorithm by which a name server prepares - a response (in RFC 1034's section 4.3.2) and the way in which - a resource record (set) is identified as being a source of - synthetic data (section 4.3.3). - - This is the definition of the term "wildcard" as it appears in - RFC 1034, section 4.3.3. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 3] - -Internet-Draft dnsext-wcard January 9, 2006 - -# In the previous algorithm, special treatment was given to RRs with -# owner names starting with the label "*". Such RRs are called -# wildcards. Wildcard RRs can be thought of as instructions for -# synthesizing RRs. When the appropriate conditions are met, the name -# server creates RRs with an owner name equal to the query name and -# contents taken from the wildcard RRs. - - This passage follows the algorithm in which the term wildcard - is first used. In this definition, wildcard refers to resource - records. In other usage, wildcard has referred to domain names, - and it has been used to describe the operational practice of - relying on wildcards to generate answers. It is clear from this - that there is a need to define clear and unambiguous terminology - in the process of discussing wildcards. - - The mention of the use of wildcards in the preparation of a - response is contained in step 3c of RFC 1034's section 4.3.2 - entitled "Algorithm." Note that "wildcard" does not appear in - the algorithm, instead references are made to the "*" label. - The portion of the algorithm relating to wildcards is - deconstructed in detail in section 3 of this document, this is - the beginning of the relevant portion of the "Algorithm." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - The scope of this document is the RFC 1034 definition of - wildcards and the implications of updates to those documents, - such as DNSSEC. Alternate schemes for synthesizing answers are - not considered. (Note that there is no reference listed. No - document is known to describe any alternate schemes, although - there has been some mention of them in mailing lists.) - -1.3 Roadmap to This Document - - This document accomplishes these three items. - o Defines new terms - o Makes minor changes to avoid conflicting concepts - o Describes the actions of certain resource records as wildcards - -1.3.1 New Terms - - To help in discussing what resource records are wildcards, two - terms will be defined - "asterisk label" and "wild card domain - name". These are defined in section 2.1.1. - - To assist in clarifying the role of wildcards in the name server - algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest - encloser" are defined. These definitions are in section 3.3.2. - "Label match" is defined in section 3.2. - -DNSEXT Working Group Expires July 9, 2006 [Page 4] - -Internet-Draft dnsext-wcard January 9, 2006 - - The new terms are used to make discussions of wildcards clearer. - Terminology doesn't directly have an impact on implementations. - -1.3.2 Changed Text - - The definition of "existence" is changed superficially. This - change will not be apparent to implementations; it is needed to - make descriptions more precise. The change appears in section - 2.2.3. - - RFC 1034, section 4.3.3., seems to prohibit having two asterisk - labels in a wildcard owner name. With this document the - restriction is removed entirely. This change and its implications - are in section 2.1.3. - - The actions when a source of synthesis owns a CNAME RR are - changed to mirror the actions if an exact match name owns a - CNAME RR. This is an addition to the words in RFC 1034, - section 4.3.2, step 3, part c. The discussion of this is in - section 3.3.3. - - Only the latter change represents an impact to implementations. - The definition of existence is not a protocol impact. The change - to the restriction on names is unlikely to have an impact, as - RFC 1034 contained no specification on when and how to enforce the - restriction. - -1.3.3 Considerations with Special Types - - This document describes semantics of wildcard RRSets for - "interesting" types as well as empty non-terminal wildcards. - Understanding these situations in the context of wildcards has - been clouded because these types incur special processing if - they are the result of an exact match. This discussion is in - section 4. - - These discussions do not have an implementation impact, they cover - existing knowledge of the types, but to a greater level of detail. - -1.4 Standards Terminology - - This document does not use terms as defined in "Key words for use - in RFCs to Indicate Requirement Levels." [RFC2119] - - Quotations of RFC 1034 are denoted by a '#' in the leftmost - column. References to section "4.3.2" are assumed to refer - to RFC 1034's section 4.3.2, simply titled "Algorithm." - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 5] - -Internet-Draft dnsext-wcard January 9, 2006 - -2. Wildcard Syntax - - The syntax of a wildcard is the same as any other DNS resource - record, across all classes and types. The only significant - feature is the owner name. - - Because wildcards are encoded as resource records with special - names, they are included in zone transfers and incremental zone - transfers[RFC1995] just as non-wildcard resource records are. - This feature has been under appreciated until discussions on - alternative approaches to wildcards appeared on mailing lists. - -2.1 Identifying a Wildcard - - To provide a more accurate description of wildcards, the - definition has to start with a discussion of the domain names - that appear as owners. Two new terms are needed, "Asterisk - Label" and "Wild Card Domain Name." - -2.1.1 Wild Card Domain Name and Asterisk Label - - A "wild card domain name" is defined by having its initial - (i.e., left-most or least significant) label be, in binary format: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC20] - for the '*' character. - - A descriptive name of a label equaling that value is an "asterisk - label." - - RFC 1034's definition of wildcard would be "a resource record - owned by a wild card domain name." - -2.1.2 Asterisks and Other Characters - - No label values other than that in section 2.1.1 are asterisk - labels, hence names beginning with other labels are never wild - card domain names. Labels such as 'the*' and '**' are not - asterisk labels so these labels do not start wild card domain - names. - -2.1.3 Non-terminal Wild Card Domain Names - - In section 4.3.3, the following is stated: - -# .......................... The owner name of the wildcard RRs is of -# the form "*.<anydomain>", where <anydomain> is any domain name. -# <anydomain> should not contain other * labels...................... - -DNSEXT Working Group Expires July 9, 2006 [Page 6] - -Internet-Draft dnsext-wcard January 9, 2006 - - The restriction is now removed. The original documentation of it - is incomplete and the restriction does not serve any purpose - given years of operational experience. - - There are three possible reasons for putting the restriction in - place, but none of the three has held up over time. One is - that the restriction meant that there would never be subdomains - of wild card domain names, but the restriciton as stated still - permits "example.*.example." for instance. Another is that - wild card domain names are not intended to be empty non-terminals, - but this situation does not disrupt the algorithm in 4.3.2. - Finally, "nested" wild card domain names are not ambiguous once - the concept of the closest encloser had been documented. - - A wild card domain name can have subdomains. There is no need - to inspect the subdomains to see if there is another asterisk - label in any subdomain. - - A wild card domain name can be an empty non-terminal. (See the - upcoming sections on empty non-terminals.) In this case, any - lookup encountering it will terminate as would any empty - non-terminal match. - -2.2 Existence Rules - - The notion that a domain name 'exists' is mentioned in the - definition of wildcards. In section 4.3.3 of RFC 1034: - -# Wildcard RRs do not apply: -# -... -# - When the query name or a name between the wildcard domain and -# the query name is know[n] to exist. For example, if a wildcard - - "Existence" is therefore an important concept in the understanding - of wildcards. Unfortunately, the definition of what exists, in RFC - 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is - taken at the definition of existence. - -2.2.1 An Example - - To illustrate what is meant by existence consider this complete - zone: - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 7] - -Internet-Draft dnsext-wcard January 9, 2006 - - $ORIGIN example. - example. 3600 IN SOA <SOA RDATA> - example. 3600 NS ns.example.com. - example. 3600 NS ns.example.net. - *.example. 3600 TXT "this is a wild card" - *.example. 3600 MX 10 host1.example. - sub.*.example. 3600 TXT "this is not a wild card" - host1.example. 3600 A 192.0.4.1 - _ssh._tcp.host1.example. 3600 SRV <SRV RDATA> - _ssh._tcp.host2.example. 3600 SRV <SRV RDATA> - subdel.example. 3600 NS ns.example.com. - subdel.example. 3600 NS ns.example.net. - - A look at the domain names in a tree structure is helpful: - - | - -------------example------------ - / / \ \ - / / \ \ - / / \ \ - * host1 host2 subdel - | | | - | | | - sub _tcp _tcp - | | - | | - _ssh _ssh - - The following responses would be synthesized from one of the - wildcards in the zone: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*.example.' - - QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN - the answer will be "foo.bar.example. IN TXT ..." - because bar.example. does not exist, but the wildcard - does. - - The following responses would not be synthesized from any of the - wildcards in the zone: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - - QNAME=sub.*.example., QTYPE=MX, QCLASS=IN - because sub.*.example. exists - -DNSEXT Working Group Expires July 9, 2006 [Page 8] - -Internet-Draft dnsext-wcard January 9, 2006 - - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists (and is a zone cut) - - QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN - because *.example. exists - - The final example highlights one common misconception about - wildcards. A wildcard "blocks itself" in the sense that a - wildcard does not match its own subdomains. I.e. "*.example." - does not match all names in the "example." zone, it fails to - match the names below "*.example." To cover names under - "*.example.", another wild card domain name is needed - - "*.*.example." - which covers all but it's own subdomains. - -2.2.2 Empty Non-terminals - - Empty non-terminals [RFC2136, Section 7.16] are domain names - that own no resource records but have subdomains that do. In - section 2.2.1, "_tcp.host1.example." is an example of a empty - non-terminal name. Empty non-terminals are introduced by this - text in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on -# the tree corresponds to a resource set (which may be empty). The -# domain system makes no distinctions between the uses of the -# interior nodes and leaves, and this memo uses the term "node" to -# refer to both. - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized, and that empty non-terminals - "exist." - - Pedantically reading the above paragraph can lead to an - interpretation that all possible domains exist - up to the - suggested limit of 255 octets for a domain name [RFC1035]. - For example, www.example. may have an A RR, and as far as is - practically concerned, is a leaf of the domain tree. But the - definition can be taken to mean that sub.www.example. also - exists, albeit with no data. By extension, all possible domains - exist, from the root on down. - - As RFC 1034 also defines "an authoritative name error indicating - that the name does not exist" in section 4.3.1, so this apparently - is not the intent of the original definition, justifying the - need for an updated definition in the next section. - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 9] - -Internet-Draft dnsext-wcard January 9, 2006 - -2.2.3 Yet Another Definition of Existence - - RFC1034's wording is fixed by the following paragraph: - - The domain name space is a tree structure. Nodes in the tree - either own at least one RRSet and/or have descendants that - collectively own at least one RRSet. A node may exist with no - RRSets only if it has descendents that do, this node is an empty - non-terminal. - - A node with no descendants is a leaf node. Empty leaf nodes do - not exist. - - Note that at a zone boundary, the domain name owns data, - including the NS RR set. In the delegating zone, the NS RR - set is not authoritative, but that is of no consequence here. - The domain name owns data, therefore, it exists. - -2.3 When is a Wild Card Domain Name Not Special - - When a wild card domain name appears in a message's query section, - no special processing occurs. An asterisk label in a query name - only matches a single, corresponding asterisk label in the - existing zone tree when the 4.3.2 algorithm is being followed. - - When a wild card domain name appears in the resource data of a - record, no special processing occurs. An asterisk label in that - context literally means just an asterisk. - -3. Impact of a Wild Card Domain Name On a Response - - RFC 1034's description of how wildcards impact response - generation is in its section 4.3.2. That passage contains the - algorithm followed by a server in constructing a response. - Within that algorithm, step 3, part 'c' defines the behavior of - the wildcard. - - The algorithm in section 4.3.2. is not intended to be pseudo-code, - i.e., its steps are not intended to be followed in strict order. - The "algorithm" is a suggested means of implementing the - requirements. As such, in step 3, parts a, b, and c, do not have - to be implemented in that order, provided that the result of the - implemented code is compliant with the protocol's specification. - -3.1 Step 2 - - Step 2 of section 4.3.2 reads: - -# 2. Search the available zones for the zone which is the nearest -# ancestor to QNAME. If such a zone is found, go to step 3, -# otherwise step 4. - -DNSEXT Working Group Expires July 9, 2006 [Page 10] - -Internet-Draft dnsext-wcard January 9, 2006 - - In this step, the most appropriate zone for the response is - chosen. The significance of this step is that it means all of - step 3 is being performed within one zone. This has significance - when considering whether or not an SOA RR can be ever be used for - synthesis. - -3.2 Step 3 - - Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. - But the beginning of the step is important and needs explanation. - -# 3. Start matching down, label by label, in the zone. The -# matching process can terminate several ways: - - The word 'matching' refers to label matching. The concept - is based in the view of the zone as the tree of existing names. - The query name is considered to be an ordered sequence of - labels - as if the name were a path from the root to the owner - of the desired data. (Which it is - 3rd paragraph of RFC 1034, - section 3.1.) - - The process of label matching a query name ends in exactly one of - three choices, the parts 'a', 'b', and 'c'. Either the name is - found, the name is below a cut point, or the name is not found. - - Once one of the parts is chosen, the other parts are not - considered. (E.g., do not execute part 'c' and then change - the execution path to finish in part 'b'.) The process of label - matching is also done independent of the query type (QTYPE). - - Parts 'a' and 'b' are not an issue for this clarification as they - do not relate to record synthesis. Part 'a' is an exact match - that results in an answer, part 'b' is a referral. - -3.3 Part 'c' - - The context of part 'c' is that the process of label matching the - labels of the query name has resulted in a situation in which - there is no corresponding label in the tree. It is as if the - lookup has "fallen off the tree." - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if [...] -# the "*" label exists. - - To help describe the process of looking 'to see if [...] the "*" - label exists' a term has been coined to describe the last domain - (node) matched. The term is "closest encloser." - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 11] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.1 Closest Encloser and the Source of Synthesis - - The closest encloser is the node in the zone's tree of existing - domain names that has the most labels matching the query name - (consecutively, counting from the root label downward). Each match - is a "label match" and the order of the labels is the same. - - The closest encloser is, by definition, an existing name in the - zone. The closest encloser might be an empty non-terminal or even - be a wild card domain name itself. In no circumstances is the - closest encloser to be used to synthesize records for the current - query. - - The source of synthesis is defined in the context of a query - process as that wild card domain name immediately descending - from the closest encloser, provided that this wild card domain - name exists. "Immediately descending" means that the source - of synthesis has a name of the form: - <asterisk label>.<closest encloser>. - A source of synthesis does not guarantee having a RRSet to use - for synthesis. The source of synthesis could be an empty - non-terminal. - - If the source of synthesis does not exist (not on the domain - tree), there will be no wildcard synthesis. There is no search - for an alternate. - - The important concept is that for any given lookup process, there - is at most one place at which wildcard synthetic records can be - obtained. If the source of synthesis does not exist, the lookup - terminates, the lookup does not look for other wildcard records. - -3.3.2 Closest Encloser and Source of Synthesis Examples - - To illustrate, using the example zone in section 2.2.1 of this - document, the following chart shows QNAMEs and the closest - enclosers. - - QNAME Closest Encloser Source of Synthesis - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no source - _telnet._tcp.host2.example. host2.example. no source - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - foobar.*.example. *.example. no source - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 12] - -Internet-Draft dnsext-wcard January 9, 2006 - -3.3.3 Type Matching - - RFC 1034 concludes part 'c' with this: - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. -# -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - The final paragraph covers the role of the QTYPE in the lookup - process. - - Based on implementation feedback and similarities between step - 'a' and step 'c' a change to this passage has been made. - - The change is to add the following text to step 'c' prior to the - instructions to "go to step 6": - - If the data at the source of synthesis is a CNAME, and - QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response changing the owner name - to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - This is essentially the same text in step a covering the - processing of CNAME RRSets. - -4. Considerations with Special Types - - Sections 2 and 3 of this document discuss wildcard synthesis - with respect to names in the domain tree and ignore the impact - of types. In this section, the implication of wildcards of - specific types are discussed. The types covered are those - that have proven to be the most difficult to understand. The - types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and - "none," i.e., empty non-terminal wild card domain names. - -4.1 SOA RRSet at a Wild Card Domain Name - - A wild card domain name owning an SOA RRSet means that the - domain is at the root of the zone (apex). The domain can not - be a source of synthesis because that is, by definition, a - descendent node (of the closest encloser) and a zone apex is - at the top of the zone. - - -DNSEXT Working Group Expires July 9, 2006 [Page 13] - -Internet-Draft dnsext-wcard January 9, 2006 - - Although a wild card domain name owning an SOA RRSet can never - be a source of synthesis, there is no reason to forbid the - ownership of an SOA RRSet. - - E.g., given this zone: - $ORIGIN *.example. - @ 3600 IN SOA <SOA RDATA> - 3600 NS ns1.example.com. - 3600 NS ns1.example.net. - www 3600 TXT "the www txt record" - - A query for www.*.example.'s TXT record would still find the - "the www txt record" answer. The asterisk label only becomes - significant when section 4.3.2, step 3 part 'c' is in effect. - - Of course, there would need to be a delegation in the parent - zone, "example." for this to work too. This is covered in the - next section. - -4.2 NS RRSet at a Wild Card Domain Name - - With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now - in place, the semantics of a wild card domain name owning an - NS RRSet has come to be poorly defined. The dilemma relates to - a conflict between the rules for synthesis in part 'c' and the - fact that the resulting synthesis generates a record for which - the zone is not authoritative. In a DNSSEC signed zone, the - mechanics of signature management (generation and inclusion - in a message) have become unclear. - - Salient points of the working group discussion on this topic is - summarized in section 4.2.1. - - As a result of these discussion, there is no definition given for - wild card domain names owning an NS RRSet. The semantics are - left undefined until there is a clear need to have a set defined, - and until there is a clear direction to proceed. Operationally, - inclusion of wild card NS RRSets in a zone is discouraged, but - not barred. - -4.2.1 Discarded Notions - - Prior to DNSSEC, a wild card domain name owning a NS RRSet - appeared to be workable, and there are some instances in which - it is found in deployments using implementations that support - this. Continuing to allow this in the specification is not - tenable with DNSSEC. The reason is that the synthesis of the - NS RRSet is being done in a zone that has delegated away the - responsibility for the name. This "unauthorized" synthesis is - not a problem for the base DNS protocol, but DNSSEC, in affirming - the authorization model for DNS exposes the problem. - -DNSEXT Working Group Expires July 9, 2006 [Page 14] - -Internet-Draft dnsext-wcard January 9, 2006 - - Outright banning of wildcards of type NS is also untenable as - the DNS protocol does not define how to handle "illegal" data. - Implementations may choose not to load a zone, but there is no - protocol definition. The lack of the definition is complicated - by having to cover dynamic update [RFC 2136], zone transfers, - as well as loading at the master server. The case of a client - (resolver, caching server) getting a wildcard of type NS in - a reply would also have to be considered. - - Given the daunting challenge of a complete definition of how to - ban such records, dealing with existing implementations that - permit the records today is a further complication. There are - uses of wild card domain name owning NS RRSets. - - One compromise proposed would have redefined wildcards of type - NS to not be used in synthesis, this compromise fell apart - because it would have required significant edits to the DNSSEC - signing and validation work. (Again, DNSSEC catches - unauthorized data.) - - With no clear consensus forming on the solution to this dilemma, - and the realization that wildcards of type NS are a rarity in - operations, the best course of action is to leave this open-ended - until "it matters." - -4.3 CNAME RRSet at a Wild Card Domain Name - - The issue of a CNAME RRSet owned by a wild card domain name has - prompted a suggested change to the last paragraph of step 3c of - the algorithm in 4.3.2. The changed text appears in section - 3.3.3 of this document. - -4.4 DNAME RRSet at a Wild Card Domain Name - - Ownership of a DNAME [RFC2672] RRSet by a wild card domain name - represents a threat to the coherency of the DNS and is to be - avoided or outright rejected. Such a DNAME RRSet represents - non-deterministic synthesis of rules fed to different caches. - As caches are fed the different rules (in an unpredictable - manner) the caches will cease to be coherent. ("As caches - are fed" refers to the storage in a cache of records obtained - in responses by recursive or iterative servers.) - - For example, assume one cache, responding to a recursive - request, obtains the record: - "a.b.example. DNAME foo.bar.example.net." - and another cache obtains: - "b.example. DNAME foo.bar.example.net." - both generated from the record: - "*.example. DNAME foo.bar.example.net." - by an authoritative server. - -DNSEXT Working Group Expires July 9, 2006 [Page 15] - -Internet-Draft dnsext-wcard January 9, 2006 - - The DNAME specification is not clear on whether DNAME records - in a cache are used to rewrite queries. In some interpretations, - the rewrite occurs, in some, it is not. Allowing for the - occurrence of rewriting, queries for "sub.a.b.example. A" may - be rewritten as "sub.foo.bar.tld. A" by the former caching - server and may be rewritten as "sub.a.foo.bar.tld. A" by the - latter. Coherency is lost, an operational nightmare ensues. - - Another justification for banning or avoiding wildcard DNAME - records is the observation that such a record could synthesize - a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." - There is a restriction in the DNAME definition that no domain - exist below a DNAME-owning domain, hence, the wildcard DNAME - is not to be permitted. - -4.5 SRV RRSet at a Wild Card Domain Name - - The definition of the SRV RRset is RFC 2782 [RFC2782]. In the - definition of the record, there is some confusion over the term - "Name." The definition reads as follows: - -# The format of the SRV RR -... -# _Service._Proto.Name TTL Class SRV Priority Weight Port Target -... -# Name -# The domain this RR refers to. The SRV RR is unique in that the -# name one searches for is not this name; the example near the end -# shows this clearly. - - Do not confuse the definition "Name" with the owner name. I.e., - once removing the _Service and _Proto labels from the owner name - of the SRV RRSet, what remains could be a wild card domain name - but this is immaterial to the SRV RRSet. - - E.g., If an SRV record is: - _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. - - *.example is a wild card domain name and although it is the Name - of the SRV RR, it is not the owner (domain name). The owner - domain name is "_foo._udp.*.example." which is not a wild card - domain name. - - The confusion is likely based on the mixture of the specification - of the SRV RR and the description of a "use case." - -4.6 DS RRSet at a Wild Card Domain Name - - A DS RRSet owned by a wild card domain name is meaningless and - harmless. This statement is made in the context that an NS RRSet - at a wild card domain name is undefined. At a non-delegation - -DNSEXT Working Group Expires July 9, 2006 [Page 16] - -Internet-Draft dnsext-wcard January 9, 2006 - - point, a DS RRSet has no value (no corresponding DNSKEY RRSet - will be used in DNSSEC validation). If there is a synthesized - DS RRSet, it alone will not be very useful as it exists in the - context of a delegation point. - -4.7 NSEC RRSet at a Wild Card Domain Name - - Wild card domain names in DNSSEC signed zones will have an NSEC - RRSet. Synthesis of these records will only occur when the - query exactly matches the record. Synthesized NSEC RR's will not - be harmful as they will never be used in negative caching or to - generate a negative response. [RFC2308] - -4.8 RRSIG at a Wild Card Domain Name - - RRSIG records will be present at a wild card domain name in a - signed zone, and will be synthesized along with data sought in a - query. The fact that the owner name is synthesized is not a - problem as the label count in the RRSIG will instruct the - verifying code to ignore it. - -4.9 Empty Non-terminal Wild Card Domain Name - - If a source of synthesis is an empty non-terminal, then the - response will be one of no error in the return code and no RRSet - in the answer section. - -5. Security Considerations - - This document is refining the specifications to make it more - likely that security can be added to DNS. No functional - additions are being made, just refining what is considered - proper to allow the DNS, security of the DNS, and extending - the DNS to be more predictable. - -6. IANA Considerations - - None. - -7. References - - Normative References - - [RFC20] ASCII Format for Network Interchange, V.G. Cerf, - Oct-16-1969 - - [RFC1034] Domain Names - Concepts and Facilities, - P.V. Mockapetris, Nov-01-1987 - - [RFC1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - - [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 - - [RFC2119] Key Words for Use in RFCs to Indicate Requirement - Levels, S Bradner, March 1997 - - [RFC2308] Negative Caching of DNS Queries (DNS NCACHE), - M. Andrews, March 1998 - - [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, - August 1999. - - [RFC2782] A DNS RR for specifying the location of services (DNS - SRV), A. Gulbrandsen, et.al., February 2000 - - [RFC4033] DNS Security Introduction and Requirements, R. Arends, - et.al., March 2005 - - [RFC4034] Resource Records for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - [RFC4035] Protocol Modifications for the DNS Security Extensions, - R. Arends, et.al., March 2005 - - Informative References - - [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - April 1997 - -8. Editor - - Name: Edward Lewis - Affiliation: NeuStar - Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US - Phone: +1-571-434-5468 - Email: ed.lewis@neustar.biz - - Comments on this document can be sent to the editor or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - -9. Others Contributing to the Document - - This document represents the work of a large working group. The - editor merely recorded the collective wisdom of the working group. - - - - - - - - - -DNSEXT Working Group Expires July 9, 2006 [Page 17] - -Internet-Draft dnsext-wcard January 9, 2006 - -10. Trailing Boilerplate - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided - on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION - HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET - SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL - WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO - ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT - INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of - any Intellectual Property Rights or other rights that might - be claimed to pertain to the implementation or use of the - technology described in this document or the extent to which - any license under such rights might or might not be available; - nor does it represent that it has made any independent effort - to identify any such rights. Information on the procedures - with respect to rights in RFC documents can be found in BCP 78 - and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the - use of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR - repository at http://www.ietf.org/ipr. The IETF invites any - interested party to bring to its attention any copyrights, - patents or patent applications, or other proprietary rights - that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - -Expiration - - This document expires on or about July 9, 2006. - - - -DNSEXT Working Group Expires July 9, 2006 [Page 19] diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt deleted file mode 100644 index 0855ba3..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: August 14, 2006 VeriSign - February 10, 2006 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-05 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 14, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This memo describes DNS iterative resolver behavior that results in a - significant query volume sent to the root and top-level domain (TLD) - name servers. We offer implementation advice to iterative resolver - developers to alleviate these unnecessary queries. The - recommendations made in this document are a direct byproduct of - observation and analysis of abnormal query traffic patterns seen at - two of the thirteen root name servers and all thirteen com/net TLD - name servers. - - - -Larson & Barber Expires August 14, 2006 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. A note about terminology in this memo . . . . . . . . . . 3 - 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5 - 2.1. Aggressive requerying for delegation information . . . . . 5 - 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6 - 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7 - 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7 - 2.3. Inability to follow multiple levels of indirection . . . . 8 - 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9 - 2.4. Aggressive retransmission when fetching glue . . . . . . . 9 - 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10 - 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10 - 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11 - 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11 - 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12 - 2.7. Name server records with zero TTL . . . . . . . . . . . . 12 - 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13 - 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13 - 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 - 2.9. Queries for domain names resembling IPv4 addresses . . . . 14 - 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14 - 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15 - 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15 - 2.11. Suboptimal name server selection algorithm . . . . . . . . 15 - 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16 - 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 - 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 - 5. Security considerations . . . . . . . . . . . . . . . . . . . 19 - 6. Internationalization considerations . . . . . . . . . . . . . 20 - 7. Informative References . . . . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 - Intellectual Property and Copyright Statements . . . . . . . . . . 22 - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net TLD name servers has revealed that a large - proportion of the total traffic often consists of "requeries". A - requery is the same question (<QNAME, QTYPE, QCLASS>) asked - repeatedly at an unexpectedly high rate. We have observed requeries - from both a single IP address and multiple IP addresses (i.e., the - same query received simultaneously from multiple IP addresses). - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient iterative resolver, - stub resolver or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of indirection must be followed, and aggressive retry by stub - resolvers or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (DoS attacks, crashes, maintenance, routing failures, - congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. None of the changes recommended affects the core DNS protocol - specification; instead, this document consists of guidelines to - implementors of iterative resolvers. - -1.1. A note about terminology in this memo - - To recast an old saying about standards, the nice thing about DNS - terms is that there are so many of them to choose from. Writing or - talking about DNS can be difficult and cause confusion resulting from - a lack of agreed-upon terms for its various components. Further - complicating matters are implementations that combine multiple roles - into one piece of software, which makes naming the result - problematic. An example is the entity that accepts recursive - queries, issues iterative queries as necessary to resolve the initial - recursive query, caches responses it receives, and which is also able - to answer questions about certain zones authoritatively. This entity - is an iterative resolver combined with an authoritative name server - and is often called a "recursive name server" or a "caching name - server". - - This memo is concerned principally with the behavior of iterative - resolvers, which are typically found as part of a recursive name - server. This memo uses the more precise term "iterative resolver", - - - -Larson & Barber Expires August 14, 2006 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - because the focus is usually on that component. In instances where - the name server role of this entity requires mentioning, this memo - uses the term "recursive name server". As an example of the - difference, the name server component of a recursive name server - receives DNS queries and the iterative resolver component sends - queries. - - The advent of IPv6 requires mentioning AAAA records as well as A - records when discussing glue. To avoid continuous repetition and - qualification, this memo uses the general term "address record" to - encompass both A and AAAA records when a particular situation is - relevant to both types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -2. Observed iterative resolver misbehavior - -2.1. Aggressive requerying for delegation information - - There can be times when every name server in a zone's NS RRset is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host) or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider an iterative resolver - that attempts to resolve a query for a domain name in such a zone and - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation whose - iterative resolver then verifies the zone's NS RRset in its cache by - querying for the zone's delegation information: it sends a query for - the zone's NS RRset to one of the parent zone's name servers. (Note - that queries with QTYPE=NS are not required by the standard - resolution algorithm described in section 4.3.2 of RFC 1034 [2]. - These NS queries represent this implementation's addition to that - algorithm.) - - For example, suppose that "example.com" has the following NS RRset: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this iterative resolver implementation immediately queries a - "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This implementation performs - this query to a zone's parent zone for each recursive query it - receives that fails because of a completely unresponsive set of name - servers for the target zone. Consider the effect when a popular zone - experiences a catastrophic failure of all its name servers: now every - recursive query for domain names in that zone sent to this recursive - name server implementation results in a query to the failed zone's - parent name servers. On one occasion when several dozen popular - zones became unreachable, the query load on the com/net name servers - increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: When an iterative resolver is resolving a query for a - domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent would be pointless: this query to the parent would come so - quickly on the heels of the referral that it would be almost certain - - - -Larson & Barber Expires August 14, 2006 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - to contain the same list of name servers. The chance of discovering - any new information is slim. - - The other possibility is that the iterative resolver successfully - contacts one of the target zone's name servers and then caches the NS - RRset from the authority section of a response, the proper behavior - according to section 5.4.1 of RFC 2181 [3], because the NS RRset from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the iterative resolver discovers that none of the name servers - specified in the cached NS RRset is available or authoritative, - querying the parent would be wrong. An NS RRset from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured or decommissioned AND the - delegation information in the parent zone would have to be updated - with the new set of name servers, all within the TTL of the target - zone's NS RRset. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually when at all possible, with servers - removed from the NS RRset left authoritative for the zone as long as - possible. The scenarios that we can envision that would benefit from - the parent requery behavior do not outweigh its damaging effects. - - This section should not be understood to claim that all queries to a - zone's parent are bad. In some cases, such queries are not only - reasonable but required. Consider the situation when required - information, such as the address of a name server (i.e., the address - record corresponding to the RDATA of an NS record), has timed out of - an iterative resolver's cache before the corresponding NS record. If - the name of the name server is below the apex of the zone, then the - name server's address record is only available as glue in the parent - zone. For example, consider this NS record: - - example.com. IN NS ns.example.com. - - If a cache has this NS record but not the address record for - "ns.example.com", it is unable to contact the "example.com" zone - directly and must query the "com" zone to obtain the address record. - Note, however, that such a query would not have QTYPE=NS according to - the standard resolution algorithm. - -2.1.1. Recommendation - - An iterative resolver MUST NOT send a query for the NS RRset of a - non-responsive zone to any of the name servers for that zone's parent - - - -Larson & Barber Expires August 14, 2006 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - zone. For the purposes of this injunction, a non-responsive zone is - defined as a zone for which every name server listed in the zone's NS - RRset: - - 1. is not authoritative for the zone (i.e., lame), or, - - 2. returns a server failure response (RCODE=2), or, - - 3. is dead or unreachable according to section 7.2 of RFC 2308 [4]. - -2.2. Repeated queries to lame servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is when a subset of a zone's name servers - are unavailable or misconfigured. Different failure modes have - different expected durations. Some symptoms indicate problems that - are potentially transient; for example, various types of ICMP - unreachable messages because a name server process is not running or - a host or network is unreachable, or a complete lack of a response to - a query. Such responses could be the result of a host rebooting or - temporary outages; these events don't necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - - It should also be noted, however, that some authoritative name server - implementations appear to be lame only for queries of certain types - as described in RFC 4074 [5]. In this case, it makes sense to retry - the "lame" servers for other types of queries, particularly when all - known authoritative name servers appear to be "lame". - -2.2.1. Recommendation - - Iterative resolvers SHOULD cache name servers that they discover are - not authoritative for zones delegated to them (i.e. lame servers). - If this caching is performed, lame servers MUST be cached against the - specific query tuple <zone name, class, server IP address>. Zone - name can be derived from the owner name of the NS record that was - referenced to query the name server that was discovered to be lame. - - - -Larson & Barber Expires August 14, 2006 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers based on a time interval from - when the server is discovered to be lame. A minimum interval of - thirty minutes is RECOMMENDED. - - An exception to this recommendation occurs if all name servers for a - zone are marked lame. In that case, the iterative resolver SHOULD - temporarily ignore the servers' lameness status and query one or more - servers. This behavior is a workaround for the type-specific - lameness issue described in the previous section. - - Implementors should take care not to make lame server avoidance logic - overly broad: note that a name server could be lame for a parent zone - but not a child zone, e.g., lame for "example.com" but properly - authoritative for "sub.example.com". Therefore a name server should - not be automatically considered lame for subzones. In the case - above, even if a name server is known to be lame for "example.com", - it should be queried for QNAMEs at or below "sub.example.com" if an - NS record indicates it should be authoritative for that zone. - -2.3. Inability to follow multiple levels of indirection - - Some iterative resolver implementations are unable to follow - sufficient levels of indirection. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - An iterative resolver resolving the name "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" or "ns2.test.example.net" in order to obtain - address records for "ns1.example.com" or "ns2.example.com" in order - to query those name servers for the address records of - "www.foo.example". While this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - top-level domains (gTLDs) become active. We anticipate many zones in - new gTLDs will use name servers in existing gTLDs, increasing the - number of delegations using out-of-zone name servers. - - - - - - -Larson & Barber Expires August 14, 2006 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -2.3.1. Recommendation - - Clearly constructing a delegation that relies on multiple levels of - indirection is not a good administrative practice. However, the - practice is widespread enough to require that iterative resolvers be - able to cope with it. Iterative resolvers SHOULD be able to handle - arbitrary levels of indirection resulting from out-of-zone name - servers. Iterative resolvers SHOULD implement a level-of-effort - counter to avoid loops or otherwise performing too much work in - resolving pathological cases. - - A best practice that avoids this entire issue of indirection is to - name one or more of a zone's name servers in the zone itself. For - example, if the zone is named "example.com", consider naming some of - the name servers "ns{1,2,...}.example.com" (or similar). - -2.4. Aggressive retransmission when fetching glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include address records for every NS record in - the authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing address records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such an entity will not - normally generate any queries of its own. Instead it answers non- - recursive queries from iterative resolvers looking for information in - zones it serves. With glue fetching enabled, however, an - authoritative server invokes an iterative resolver to look up an - unknown address record to complete the additional section of a - response. - - We have observed situations where the iterative resolver of a glue- - fetching name server can send queries that reach other name servers, - but is apparently prevented from receiving the responses. For - example, perhaps the name server is authoritative-only and therefore - its administrators expect it to receive only queries and not - responses. Perhaps unaware of glue fetching and presuming that the - name server's iterative resolver will generate no queries, its - administrators place the name server behind a network device that - - - -Larson & Barber Expires August 14, 2006 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - prevents it from receiving responses. If this is the case, all glue- - fetching queries will go answered. - - We have observed name server implementations whose iterative - resolvers retry excessively when glue-fetching queries are - unanswered. A single com/net name server has received hundreds of - queries per second from a single such source. Judging from the - specific queries received and based on additional analysis, we - believe these queries result from overly aggressive glue fetching. - -2.4.1. Recommendation - - Implementers whose name servers support glue fetching SHOULD take - care to avoid sending queries at excessive rates. Implementations - SHOULD support throttling logic to detect when queries are sent but - no responses are received. - -2.5. Aggressive retransmission behind firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, an - iterative resolver is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose iterative resolvers' - traffic is improperly filtered in this manner. Stub resolvers in the - organization could be configured to query multiple recursive name - servers. Consider the case where a stub resolver queries a filtered - recursive name server first. The iterative resolver of this - recursive name server sends one or more queries whose replies are - filtered, so it can't respond to the stub resolver, which times out. - Then the stub resolver retransmits to a recursive name server that is - able to provide an answer. Since resolution ultimately succeeds the - underlying problem might not be recognized or corrected. A popular - stub resolver implementation has a very aggressive retransmission - schedule, including simultaneous queries to multiple recursive name - - - -Larson & Barber Expires August 14, 2006 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - servers, which could explain how such a situation could persist - without being detected. - -2.5.1. Recommendation - - The most obvious recommendation is that administrators SHOULD take - care not to place iterative resolvers behind a firewall that allows - queries to pass through but not the resulting replies. - - Iterative resolvers SHOULD take care to avoid sending queries at - excessive rates. Implementations SHOULD support throttling logic to - detect when queries are sent but no responses are received. - -2.6. Misconfigured NS records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. An iterative resolver - attempting to resolve address records for "www.example.com" with no - cached information for this zone will query a "com" authoritative - server. The "com" server responds with a referral to the - "example.com" zone, consisting of NS records with valid RDATA and - associated glue records. (This example assumes that the - "example.com" zone delegation information is correct in the "com" - zone.) The iterative resolver caches the NS RRset from the "com" - server and follows the referral by querying one of the "example.com" - authoritative servers. This server responds with the - "www.example.com" address record in the answer section and, - typically, the "example.com" NS records in the authority section and, - if space in the message remains, glue address records in the - additional section. According to Section 5.4 of RFC 2181 [3], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a non- - authoritative answer. Thus the "example.com" NS RRset just received - from the "example.com" authoritative server overrides the - "example.com" NS RRset received moments ago from the "com" - - - -Larson & Barber Expires August 14, 2006 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - authoritative server. - - But the "example.com" zone contains the erroneous NS RRset as shown - in the example above. Subsequent queries for names in "example.com" - will cause the iterative resolver to attempt to use the incorrect NS - records and so it will try to resolve the nonexistent names - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the iterative resolver cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in address - record queries to the "com" authoritative servers. Queries for such - obviously bogus glue address records occur frequently at the com/net - name servers. - -2.6.1. Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that exists somewhere under the apex of the zone the - NS record appears in. Note that further levels of delegation are - possible, so a missing trailing dot could inadvertently create a name - server name that actually exists in a subzone. - - An authoritative name server SHOULD issue a warning when one of a - zone's NS records references a name server below the zone's apex when - a corresponding address record does not exist in the zone AND there - are no delegated subzones where the address record could exist. - -2.7. Name server records with zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRset, however, carries - additional consequences beyond the zone itself: if an iterative - resolver cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRset expected to change frequently is extreme but - permissible. A zone's NS RRset is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - - - -Larson & Barber Expires August 14, 2006 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - zone parent/child relationships we are aware of, there is typically - some delay involved in effecting changes. Further, changes to the - set of a zone's authoritative name servers (and therefore to the - zone's NS RRset) are typically relatively rare: providing reliable - authoritative service requires a reasonably stable set of servers. - Therefore an extremely low or zero TTL on a zone's NS RRset rarely - makes sense, except in anticipation of an upcoming change. In this - case, when the zone's administrator has planned a change and does not - want iterative resolvers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - -2.7.1. Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers resulting from a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers SHOULD issue a - warning when loading a zone. - -2.8. Unnecessary dynamic update messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's SOA MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone entails walking up the name - space tree by sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an address record with - the name "foo.bar.example.com". The agent could first attempt to - update the "foo.bar.example.com" zone. If the attempt failed, the - update could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A valid question is why the algorithm proceeds to send - updates all the way to TLD and root name servers. This behavior is - not entirely unreasonable: in enterprise DNS architectures with an - "internal root" design, there could conceivably be private, non- - - - -Larson & Barber Expires August 14, 2006 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - public TLD or root zones that would be the appropriate targets for a - dynamic update. - - A significant deficiency with this algorithm is that knowledge of a - given UPDATE message's failure is not helpful in directing future - UPDATE messages to the appropriate servers. A better algorithm would - be to find the closest enclosing zone by walking up the name space - with queries for SOA or NS rather than "probing" with UPDATE - messages. Once the appropriate zone is found, an UPDATE message can - be sent. In addition, the results of these queries can be cached to - aid in determining closest enclosing zones for future updates. Once - the closest enclosing zone is determined with this method, the update - will either succeed or fail and there is no need to send further - updates to higher-level zones. The important point is that walking - up the tree with queries yields cacheable information, whereas - walking up the tree by sending UPDATE messages does not. - -2.8.1. Recommendation - - Dynamic update agents SHOULD send SOA or NS queries to progressively - higher-level names to find the closest enclosing zone for a given - name to update. Only after the appropriate zone is found should the - client send an UPDATE message to one of the zone's authoritative - servers. Update clients SHOULD NOT "probe" using UPDATE messages by - walking up the tree to progressively higher-level zones. - -2.9. Queries for domain names resembling IPv4 addresses - - The root name servers receive a significant number of A record - queries where the QNAME looks like an IPv4 address. The source of - these queries is unknown. It could be attributed to situations where - a user believes an application will accept either a domain name or an - IP address in a given configuration option. The user enters an IP - address, but the application assumes any input is a domain name and - attempts to resolve it, resulting in an A record lookup. There could - also be applications that produce such queries in a misguided attempt - to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. An iterative - resolver can negatively cache such responses, but each response - requires a separate cache entry, i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - -2.9.1. Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - - - -Larson & Barber Expires August 14, 2006 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - bandwidth. A possible solution is to delegate these numeric TLDs - from the root zone to a separate set of servers to absorb the - traffic. The "black hole servers" used by the AS 112 Project [8], - which are currently delegated the in-addr.arpa zones corresponding to - RFC 1918 [7] private use address space, would be a possible choice to - receive these delegations. Of course, the proper and usual root zone - change procedures would have to be followed to make such a change to - the root zone. - -2.10. Misdirected recursive queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the RD bit set in the header). Since - none of the root servers offers recursion, the servers' response in - such a situation ignores the request for recursion and the response - probably does not contain the data the querier anticipated. Some of - these queries result from users configuring stub resolvers to query a - root server. (This situation is not hypothetical: we have received - complaints from users when this configuration does not work as - hoped.) Of course, users should not direct stub resolvers to use - name servers that do not offer recursion, but we are not aware of any - stub resolver implementation that offers any feedback to the user - when so configured, aside from simply "not working". - -2.10.1. Recommendation - - When the IP address of a name server that supposedly offers recursion - is configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server indeed - supports recursion (i.e., verify that the response has the RA bit set - in the header). The user could be immediately notified if the server - is non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting SHOULD be throttled to avoid a - notification or log message for every response from a non-recursive - server. - -2.11. Suboptimal name server selection algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully under specified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - - -Larson & Barber Expires August 14, 2006 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by an iterative resolver. When an iterative resolver wants - to contact one of a zone's authoritative name servers, how does it - choose from the NS records listed in the zone's NS RRset? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1. Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. I.e., these changes would - help spread the query load evenly. - - o Do not make assumptions based on NS RRset order: all NS RRs SHOULD - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for "a.gtld- - servers.net" first in the authority section of referrals. - Apparently as a result, this server receives disproportionately - more traffic than the other 12 authoritative servers for "com".) - - o Use all NS records in an RRset. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. An - iterative resolver SHOULD periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -3. Acknowledgments - - The authors would like to thank the following people for their - comments that improved this document: Andras Salamon, Dave Meyer, - Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, - Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We - apologize if we have omitted anyone; any oversight was unintentional. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -4. IANA considerations - - There are no new IANA considerations introduced by this memo. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -5. Security considerations - - The iterative resolver misbehavior discussed in this document exposes - the root and TLD name servers to increased risk of both intentional - and unintentional denial of service attacks. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -6. Internationalization considerations - - There are no new internationalization considerations introduced by - this memo. - -7. Informative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS - Queries for IPv6 Addresses", RFC 4074, May 2005. - - [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. - Lear, "Address Allocation for Private Internets", BCP 5, - RFC 1918, February 1996. - - [8] <http://www.as112.net> - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 20] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - Email: mlarson@verisign.com - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - Email: pbarber@verisign.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 14, 2006 [Page 21] - -Internet-Draft Observed DNS Resolution Misbehavior February 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Larson & Barber Expires August 14, 2006 [Page 22] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt deleted file mode 100644 index 8ca68a8..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt +++ /dev/null @@ -1,2016 +0,0 @@ - - - -DNSOP O. Kolkman -Internet-Draft R. Gieben -Obsoletes: 2541 (if approved) NLnet Labs -Expires: September 7, 2006 March 6, 2006 - - - DNSSEC Operational Practices - draft-ietf-dnsop-dnssec-operational-practices-08.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 7, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document describes a set of practices for operating the DNS with - security extensions (DNSSEC). The target audience is zone - administrators deploying DNSSEC. - - The document discusses operational aspects of using keys and - signatures in the DNS. It discusses issues as key generation, key - storage, signature generation, key rollover and related policies. - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 1] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - This document obsoletes RFC 2541, as it covers more operational - ground and gives more up to date requirements with respect to key - sizes and the new DNSSEC specification. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 4 - 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5 - 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5 - 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6 - 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6 - 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7 - 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 8 - 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9 - 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9 - 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 12 - 4. Signature generation, Key Rollover and Related Policies . . . 12 - 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12 - 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13 - 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 14 - 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15 - 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19 - 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 20 - 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 21 - 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 22 - 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 22 - 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24 - 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 24 - 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 24 - 4.4.1. Initial Key Exchanges and Parental Policies - Considerations . . . . . . . . . . . . . . . . . . . . 24 - 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 25 - 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 25 - 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 26 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 - Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 29 - Appendix B. Zone Signing Key Rollover Howto . . . . . . . . . . . 30 - Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 31 - Appendix D. Document Details and Changes . . . . . . . . . . . . 33 - - - -Kolkman & Gieben Expires September 7, 2006 [Page 2] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33 - D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33 - D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33 - D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33 - D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34 - D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34 - D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34 - D.8. draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34 - D.9. draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . . . . 36 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 3] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -1. Introduction - - This document describes how to run a DNSSEC (DNS SECure) enabled - environment. It is intended for operators who have knowledge of the - DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC. See - RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the - newly introduced Resource Records and finally RFC 4035 [6] for the - protocol changes. - - During workshops and early operational deployment tests, operators - and system administrators have gained experience about operating the - DNS with security extensions (DNSSEC). This document translates - these experiences into a set of practices for zone administrators. - At the time of writing, there exists very little experience with - DNSSEC in production environments; this document should therefore - explicitly not be seen as representing 'Best Current Practices'. - - The procedures herein are focused on the maintenance of signed zones - (i.e. signing and publishing zones on authoritative servers). It is - intended that maintenance of zones such as re-signing or key - rollovers be transparent to any verifying clients on the Internet. - - The structure of this document is as follows. In Section 2 we - discuss the importance of keeping the "chain of trust" intact. - Aspects of key generation and storage of private keys are discussed - in Section 3; the focus in this section is mainly on the private part - of the key(s). Section 4 describes considerations concerning the - public part of the keys. Since these public keys appear in the DNS - one has to take into account all kinds of timing issues, which are - discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the - rollover, or supercession, of keys. Finally Section 4.4 discusses - considerations on how parents deal with their children's public keys - in order to maintain chains of trust. - - The typographic conventions used in this document are explained in - Appendix C. - - Since this is a document with operational suggestions and there are - no protocol specifications, the RFC 2119 [9] language does not apply. - - This document obsoletes RFC 2541 [12]. - -1.1. The Use of the Term 'key' - - It is assumed that the reader is familiar with the concept of - asymmetric keys on which DNSSEC is based (Public Key Cryptography - [18]). Therefore, this document will use the term 'key' rather - loosely. Where it is written that 'a key is used to sign data' it is - - - -Kolkman & Gieben Expires September 7, 2006 [Page 4] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - assumed that the reader understands that it is the private part of - the key pair that is used for signing. It is also assumed that the - reader understands that the public part of the key pair is published - in the DNSKEY resource record and that it is the public part that is - used in key exchanges. - -1.2. Time Definitions - - In this document we will be using a number of time related terms. - The following definitions apply: - o "Signature validity period" - The period that a signature is valid. It starts at the time - specified in the signature inception field of the RRSIG RR and - ends at the time specified in the expiration field of the RRSIG - RR. - o "Signature publication period" - Time after which a signature (made with a specific key) is - replaced with a new signature (made with the same key). This - replacement takes place by publishing the relevant RRSIG in the - master zone file. - After one stops publishing an RRSIG in a zone it may take a - while before the RRSIG has expired from caches and has actually - been removed from the DNS. - o "Key effectivity period" - The period during which a key pair is expected to be effective. - This period is defined as the time between the first inception - time stamp and the last expiration date of any signature made - with this key, regardless of any discontinuity in the use of - the key. - The key effectivity period can span multiple signature validity - periods. - o "Maximum/Minimum Zone Time to Live (TTL)" - The maximum or minimum value of the TTLs from the complete set - of RRs in a zone. Note that the minimum TTL is not the same as - the MINIMUM field in the SOA RR. See [11] for more - information. - - -2. Keeping the Chain of Trust Intact - - Maintaining a valid chain of trust is important because broken chains - of trust will result in data being marked as Bogus (as defined in [4] - section 5), which may cause entire (sub)domains to become invisible - to verifying clients. The administrators of secured zones have to - realize that their zone is, to verifying clients, part of a chain of - trust. - - As mentioned in the introduction, the procedures herein are intended - - - -Kolkman & Gieben Expires September 7, 2006 [Page 5] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - to ensure that maintenance of zones, such as re-signing or key - rollovers, will be transparent to the verifying clients on the - Internet. - - Administrators of secured zones will have to keep in mind that data - published on an authoritative primary server will not be immediately - seen by verifying clients; it may take some time for the data to be - transferred to other secondary authoritative nameservers and clients - may be fetching data from caching non-authoritative servers. In this - light it is good to note that the time for a zone transfer from - master to slave is negligible when using NOTIFY [8] and IXFR [7], - increasing by reliance on AXFR, and more if you rely on the SOA - timing parameters for zone refresh. - - For the verifying clients it is important that data from secured - zones can be used to build chains of trust regardless of whether the - data came directly from an authoritative server, a caching nameserver - or some middle box. Only by carefully using the available timing - parameters can a zone administrator assure that the data necessary - for verification can be obtained. - - The responsibility for maintaining the chain of trust is shared by - administrators of secured zones in the chain of trust. This is most - obvious in the case of a 'key compromise' when a trade off between - maintaining a valid chain of trust and replacing the compromised keys - as soon as possible must be made. Then zone administrators will have - to make a trade off, between keeping the chain of trust intact - - thereby allowing for attacks with the compromised key - or to - deliberately break the chain of trust and making secured sub domains - invisible to security aware resolvers. Also see Section 4.3. - - -3. Keys Generation and Storage - - This section describes a number of considerations with respect to the - security of keys. It deals with the generation, effectivity period, - size and storage of private keys. - -3.1. Zone and Key Signing Keys - - The DNSSEC validation protocol does not distinguish between different - types of DNSKEYs. All DNSKEYs can be used during the validation. In - practice operators use Key Signing and Zone Signing Keys and use the - so-called (Secure Entry Point) SEP [3] flag to distinguish between - them during operations. The dynamics and considerations are - discussed below. - - To make zone re-signing and key rollover procedures easier to - - - -Kolkman & Gieben Expires September 7, 2006 [Page 6] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - implement, it is possible to use one or more keys as Key Signing Keys - (KSK). These keys will only sign the apex DNSKEY RRSet in a zone. - Other keys can be used to sign all the RRSets in a zone and are - referred to as Zone Signing Keys (ZSK). In this document we assume - that KSKs are the subset of keys that are used for key exchanges with - the parent and potentially for configuration as trusted anchors - the - SEP keys. In this document we assume a one-to-one mapping between - KSK and SEP keys and we assume the SEP flag to be set on all KSKs. - -3.1.1. Motivations for the KSK and ZSK Separation - - Differentiating between the KSK and ZSK functions has several - advantages: - - o No parent/child interaction is required when ZSKs are updated. - o The KSK can be made stronger (i.e. using more bits in the key - material). This has little operational impact since it is only - used to sign a small fraction of the zone data. Also the KSK is - only used to verify the zone's key set, not for other RRSets in - the zone. - o As the KSK is only used to sign a key set, which is most probably - updated less frequently than other data in the zone, it can be - stored separately from and in a safer location than the ZSK. - o A KSK can have a longer key effectivity period. - - For almost any method of key management and zone signing the KSK is - used less frequently than the ZSK. Once a key set is signed with the - KSK all the keys in the key set can be used as ZSK. If a ZSK is - compromised, it can be simply dropped from the key set. The new key - set is then re-signed with the KSK. - - Given the assumption that for KSKs the SEP flag is set, the KSK can - be distinguished from a ZSK by examining the flag field in the DNSKEY - RR. If the flag field is an odd number it is a KSK. If it is an - even number it is a ZSK. - - The zone signing key can be used to sign all the data in a zone on a - regular basis. When a zone signing key is to be rolled, no - interaction with the parent is needed. This allows for "Signature - Validity Periods" on the order of days. - - The key signing key is only to be used to sign the DNSKEY RRs in a - zone. If a key signing key is to be rolled over, there will be - interactions with parties other than the zone administrator. These - can include the registry of the parent zone or administrators of - verifying resolvers that have the particular key configured as secure - entry points. Hence, the key effectivity period of these keys can - and should be made much longer. Although, given a long enough key, - - - -Kolkman & Gieben Expires September 7, 2006 [Page 7] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - the Key Effectivity Period can be on the order of years we suggest - planning for a key effectivity of the order of a few months so that a - key rollover remains an operational routine. - -3.1.2. KSKs for High Level Zones - - Higher level zones are generally more sensitive than lower level - zones. Anyone controlling or breaking the security of a zone thereby - obtains authority over all of its sub domains (except in the case of - resolvers that have locally configured the public key of a sub - domain, in which case this, and only this, sub domain wouldn't be - affected by the compromise of the parent zone). Therefore, extra - care should be taken with high level zones and strong keys should - used. - - The root zone is the most critical of all zones. Someone controlling - or compromising the security of the root zone would control the - entire DNS name space of all resolvers using that root zone (except - in the case of resolvers that have locally configured the public key - of a sub domain). Therefore, the utmost care must be taken in the - securing of the root zone. The strongest and most carefully handled - keys should be used. The root zone private key should always be kept - off line. - - Many resolvers will start at a root server for their access to and - authentication of DNS data. Securely updating the trust anchors in - an enormous population of resolvers around the world will be - extremely difficult. - -3.2. Key Generation - - Careful generation of all keys is a sometimes overlooked but - absolutely essential element in any cryptographically secure system. - The strongest algorithms used with the longest keys are still of no - use if an adversary can guess enough to lower the size of the likely - key space so that it can be exhaustively searched. Technical - suggestions for the generation of random keys will be found in RFC - 4086 [15]. One should carefully assess if the random number - generator used during key generation adheres to these suggestions. - - Keys with a long effectivity period are particularly sensitive as - they will represent a more valuable target and be subject to attack - for a longer time than short period keys. It is strongly recommended - that long term key generation occur off-line in a manner isolated - from the network via an air gap or, at a minimum, high level secure - hardware. - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 8] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -3.3. Key Effectivity Period - - For various reasons keys in DNSSEC need to be changed once in a - while. The longer a key is in use, the greater the probability that - it will have been compromised through carelessness, accident, - espionage, or cryptanalysis. Furthermore when key rollovers are too - rare an event, they will not become part of the operational habit and - there is risk that nobody on-site will remember the procedure for - rollover when the need is there. - - From a purely operational perspective a reasonable key effectivity - period for Key Signing Keys is 13 months, with the intent to replace - them after 12 months. An intended key effectivity period of a month - is reasonable for Zone Signing Keys. - - For key sizes that matches these effectivity periods see Section 3.5. - - As argued in Section 3.1.2 securely updating trust anchors will be - extremely difficult. On the other hand the "operational habit" - argument does also apply to trust anchor reconfiguration. If a short - key-effectivity period is used and the trust anchor configuration has - to be revisited on a regular basis the odds that the configuration - tends to be forgotten is smaller. The trade-off is against a system - that is so dynamic that administrators of the validating clients will - not be able to follow the modifications. - - Key effectivity periods can be made very short, as in the order of a - few minutes. But when replacing keys one has to take the - considerations from Section 4.1 and Section 4.2 into account. - -3.4. Key Algorithm - - There are currently three different types of algorithms that can be - used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter - is fairly new and has yet to be standardized for usage in DNSSEC. - - RSA has been developed in an open and transparent manner. As the - patent on RSA expired in 2000, its use is now also free. - - DSA has been developed by NIST. The creation of signatures takes - roughly the same time as with RSA, but is 10 to 40 times as slow for - verification [18]. - - We suggest the use of RSA/SHA-1 as the preferred algorithm for the - key. The current known attacks on RSA can be defeated by making your - key longer. As the MD5 hashing algorithm is showing (theoretical) - cracks, we recommend the usage of SHA-1. - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 9] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - At the time of publication it is known that the SHA-1 hash has - cryptanalysis issues. There is work in progress on addressing these - issues. We recommend the use of public key algorithms based on - hashes stronger than SHA-1, e.g. SHA-256, as soon as these - algorithms are available in protocol specifications (See [20] and - [21] ) and implementations. - -3.5. Key Sizes - - When choosing key sizes, zone administrators will need to take into - account how long a key will be used, how much data will be signed - during the key publication period (See Section 8.10 of [18]) and, - optionally, how large the key size of the parent is. As the chain of - trust really is "a chain", there is not much sense in making one of - the keys in the chain several times larger then the others. As - always, it's the weakest link that defines the strength of the entire - chain. Also see Section 3.1.1 for a discussion of how keys serving - different roles (ZSK v. KSK) may need different key sizes. - - Generating a key of the correct size is a difficult problem, RFC 3766 - [14] tries to deal with that problem. The first part of the - selection procedure in Section 1 of the RFC states: - - 1. Determine the attack resistance necessary to satisfy the - security requirements of the application. Do this by - estimating the minimum number of computer operations that - the attacker will be forced to do in order to compromise - the security of the system and then take the logarithm base - two of that number. Call that logarithm value "n". - - A 1996 report recommended 90 bits as a good all-around choice - for system security. The 90 bit number should be increased - by about 2/3 bit/year, or about 96 bits in 2005. - - [14] goes on to explain how this number "n" can be used to calculate - the key sizes in public key cryptography. This culminated in the - table given below (slightly modified for our purpose): - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 10] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - +-------------+-----------+--------------+ - | System | | | - | requirement | Symmetric | RSA or DSA | - | for attack | key size | modulus size | - | resistance | (bits) | (bits) | - | (bits) | | | - +-------------+-----------+--------------+ - | 70 | 70 | 947 | - | 80 | 80 | 1228 | - | 90 | 90 | 1553 | - | 100 | 100 | 1926 | - | 150 | 150 | 4575 | - | 200 | 200 | 8719 | - | 250 | 250 | 14596 | - +-------------+-----------+--------------+ - - The key sizes given are rather large. This is because these keys are - resilient against a trillionaire attacker. Assuming this rich - attacker will not attack your key and that the key is rolled over - once a year, we come to the following recommendations about KSK - sizes; 1024 bits low value domains, 1300 for medium value and 2048 - for the high value domains. - - Whether a domain is of low, medium, high value depends solely on the - views of the zone owner. One could for instance view leaf nodes in - the DNS as of low value and TLDs or the root zone of high value. The - suggested key sizes should be safe for the next 5 years. - - As ZSKs can be rolled over more easily (and thus more often) the key - sizes can be made smaller. But as said in the introduction of this - paragraph, making the ZSKs' key sizes too small (in relation to the - KSKs' sizes) doesn't make much sense. Try to limit the difference in - size to about 100 bits. - - Note that nobody can see into the future, and that these key sizes - are only provided here as a guide. Further information can be found - in [17] and Section 7.5 of [18]. It should be noted though that [17] - is already considered overly optimistic about what key sizes are - considered safe. - - One final note concerning key sizes. Larger keys will increase the - sizes of the RRSIG and DNSKEY records and will therefore increase the - chance of DNS UDP packet overflow. Also the time it takes to - validate and create RRSIGs increases with larger keys, so don't - needlessly double your key sizes. - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 11] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -3.6. Private Key Storage - - It is recommended that, where possible, zone private keys and the - zone file master copy that is to be signed, be kept and used in off- - line, non-network connected, physically secure machines only. - Periodically an application can be run to add authentication to a - zone by adding RRSIG and NSEC RRs. Then the augmented file can be - transferred. - - When relying on dynamic update to manage a signed zone [10], be aware - that at least one private key of the zone will have to reside on the - master server. This key is only as secure as the amount of exposure - the server receives to unknown clients and the security of the host. - Although not mandatory one could administer the DNS in the following - way. The master that processes the dynamic updates is unavailable - from generic hosts on the Internet, it is not listed in the NS RR - set, although its name appears in the SOA RRs MNAME field. The - nameservers in the NS RR set are able to receive zone updates through - NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism. This - approach is known as the "hidden master" setup. - - The ideal situation is to have a one way information flow to the - network to avoid the possibility of tampering from the network. - Keeping the zone master file on-line on the network and simply - cycling it through an off-line signer does not do this. The on-line - version could still be tampered with if the host it resides on is - compromised. For maximum security, the master copy of the zone file - should be off net and should not be updated based on an unsecured - network mediated communication. - - In general keeping a zone-file off-line will not be practical and the - machines on which zone files are maintained will be connected to a - network. Operators are advised to take security measures to shield - unauthorized access to the master copy. - - For dynamically updated secured zones [10] both the master copy and - the private key that is used to update signatures on updated RRs will - need to be on-line. - - -4. Signature generation, Key Rollover and Related Policies - -4.1. Time in DNSSEC - - Without DNSSEC all times in DNS are relative. The SOA fields - REFRESH, RETRY and EXPIRATION are timers used to determine the time - elapsed after a slave server synchronized with a master server. The - Time to Live (TTL) value and the SOA RR minimum TTL parameter [11] - - - -Kolkman & Gieben Expires September 7, 2006 [Page 12] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - are used to determine how long a forwarder should cache data after it - has been fetched from an authoritative server. By using a signature - validity period, DNSSEC introduces the notion of an absolute time in - the DNS. Signatures in DNSSEC have an expiration date after which - the signature is marked as invalid and the signed data is to be - considered Bogus. - -4.1.1. Time Considerations - - Because of the expiration of signatures, one should consider the - following: - o We suggest the Maximum Zone TTL of your zone data to be a fraction - of your signature validity period. - If the TTL would be of similar order as the signature validity - period, then all RRSets fetched during the validity period - would be cached until the signature expiration time. Section - 7.1 of [4] suggests that "the resolver may use the time - remaining before expiration of the signature validity period of - a signed RRSet as an upper bound for the TTL". As a result - query load on authoritative servers would peak at signature - expiration time, as this is also the time at which records - simultaneously expire from caches. - To avoid query load peaks we suggest the TTL on all the RRs in - your zone to be at least a few times smaller than your - signature validity period. - o We suggest the Signature Publication Period to end at least one - Maximum Zone TTL duration before the end of the Signature Validity - Period. - Re-signing a zone shortly before the end of the signature - validity period may cause simultaneous expiration of data from - caches. This in turn may lead to peaks in the load on - authoritative servers. - o We suggest the minimum zone TTL to be long enough to both fetch - and verify all the RRs in the trust chain. In workshop - environments it has been demonstrated [19] that a low TTL (under 5 - to 10 minutes) caused disruptions because of the following two - problems: - 1. During validation, some data may expire before the - validation is complete. The validator should be able to keep - all data, until is completed. This applies to all RRs needed - to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the - final answers i.e. the RRSet that is returned for the initial - query. - 2. Frequent verification causes load on recursive nameservers. - Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from - caching. The TTL on those should be relatively long. - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 13] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - o Slave servers will need to be able to fetch newly signed zones - well before the RRSIGs in the zone served by the slave server pass - their signature expiration time. - When a slave server is out of sync with its master and data in - a zone is signed by expired signatures it may be better for the - slave server not to give out any answer. - Normally a slave server that is not able to contact a master - server for an extended period will expire a zone. When that - happens the server will respond differently to queries for that - zone. Some servers issue SERVFAIL while others turn off the - 'AA' bit in the answers. The time of expiration is set in the - SOA record and is relative to the last successful refresh - between the master and the slave server. There exists no - coupling between the signature expiration of RRSIGs in the zone - and the expire parameter in the SOA. - If the server serves a DNSSEC zone then it may well happen that - the signatures expire well before the SOA expiration timer - counts down to zero. It is not possible to completely prevent - this from happening by tweaking the SOA parameters. - However, the effects can be minimized where the SOA expiration - time is equal or shorter than the signature validity period. - The consequence of an authoritative server not being able to - update a zone, whilst that zone includes expired signatures, is - that non-secure resolvers will continue to be able to resolve - data served by the particular slave servers while security - aware resolvers will experience problems because of answers - being marked as Bogus. - We suggest the SOA expiration timer being approximately one - third or one fourth of the signature validity period. It will - allow problems with transfers from the master server to be - noticed before the actual signature times out. - We also suggest that operators of nameservers that supply - secondary services develop 'watch dogs' to spot upcoming - signature expirations in zones they slave, and take appropriate - action. - When determining the value for the expiration parameter one has - to take the following into account: What are the chances that - all my secondaries expire the zone; How quickly can I reach an - administrator of secondary servers to load a valid zone? All - these arguments are not DNSSEC specific but may influence the - choice of your signature validity intervals. - -4.2. Key Rollovers - - A DNSSEC key cannot be used forever (see Section 3.3). So key - rollovers -- or supercessions, as they are sometimes called -- are a - fact of life when using DNSSEC. Zone administrators who are in the - process of rolling their keys have to take into account that data - - - -Kolkman & Gieben Expires September 7, 2006 [Page 14] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - published in previous versions of their zone still lives in caches. - When deploying DNSSEC, this becomes an important consideration; - ignoring data that may be in caches may lead to loss of service for - clients. - - The most pressing example of this occurs when zone material signed - with an old key is being validated by a resolver which does not have - the old zone key cached. If the old key is no longer present in the - current zone, this validation fails, marking the data Bogus. - Alternatively, an attempt could be made to validate data which is - signed with a new key against an old key that lives in a local cache, - also resulting in data being marked Bogus. - -4.2.1. Zone Signing Key Rollovers - - For zone signing key rollovers there are two ways to make sure that - during the rollover data still cached can be verified with the new - key sets or newly generated signatures can be verified with the keys - still in caches. One schema, described in Section 4.2.1.2, uses - double signatures; the other uses key pre-publication - (Section 4.2.1.1). The pros, cons and recommendations are described - in Section 4.2.1.3. - -4.2.1.1. Pre-publish Key Rollover - - This section shows how to perform a ZSK rollover without the need to - sign all the data in a zone twice - the so-called "pre-publish - rollover".This method has advantages in the case of a key compromise. - If the old key is compromised, the new key has already been - distributed in the DNS. The zone administrator is then able to - quickly switch to the new key and remove the compromised key from the - zone. Another major advantage is that the zone size does not double, - as is the case with the double signature ZSK rollover. A small - "HOWTO" for this kind of rollover can be found in Appendix B. - - Pre-publish Key Rollover involves four stages as follows: - - initial new DNSKEY new RRSIGs DNSKEY removal - - SOA0 SOA1 SOA2 SOA3 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) - - DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 15] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - initial: Initial version of the zone: DNSKEY 1 is the key signing - key. DNSKEY 10 is used to sign all the data of the zone, the zone - signing key. - new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no - signatures are generated with this key yet, but this does not - secure against brute force attacks on the public key. The minimum - duration of this pre-roll phase is the time it takes for the data - to propagate to the authoritative servers plus TTL value of the - key set. - new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is - used to sign the data in the zone exclusively (i.e. all the - signatures from DNSKEY 10 are removed from the zone). DNSKEY 10 - remains published in the key set. This way data that was loaded - into caches from version 1 of the zone can still be verified with - key sets fetched from version 2 of the zone. - The minimum time that the key set including DNSKEY 10 is to be - published is the time that it takes for zone data from the - previous version of the zone to expire from old caches i.e. the - time it takes for this zone to propagate to all authoritative - servers plus the Maximum Zone TTL value of any of the data in the - previous version of the zone. - DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now - only containing DNSKEY 1 and DNSKEY 11 is re-signed with the - DNSKEY 1. - - The above scheme can be simplified by always publishing the "future" - key immediately after the rollover. The scheme would look as follows - (we show two rollovers); the future key is introduced in "new DNSKEY" - as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY - (II)": - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 16] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - initial new RRSIGs new DNSKEY - - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 DNSKEY11 DNSKEY12 - RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) - - - new RRSIGs (II) new DNSKEY (II) - - SOA3 SOA4 - RRSIG12(SOA3) RRSIG12(SOA4) - - DNSKEY1 DNSKEY1 - DNSKEY11 DNSKEY12 - DNSKEY12 DNSKEY13 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG12(DNSKEY) RRSIG12(DNSKEY) - - - Pre-Publish Key Rollover, showing two rollovers. - - Note that the key introduced in the "new DNSKEY" phase is not used - for production yet; the private key can thus be stored in a - physically secure manner and does not need to be 'fetched' every time - a zone needs to be signed. - -4.2.1.2. Double Signature Zone Signing Key Rollover - - This section shows how to perform a ZSK key rollover using the double - zone data signature scheme, aptly named "double sig rollover". - - During the "new DNSKEY" stage the new version of the zone file will - need to propagate to all authoritative servers and the data that - exists in (distant) caches will need to expire, requiring at least - the maximum Zone TTL. - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 17] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - Double Signature Zone Signing Key Rollover involves three stages as - follows: - - initial new DNSKEY DNSKEY removal - - SOA0 SOA1 SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) - RRSIG11(SOA1) - - DNSKEY1 DNSKEY1 DNSKEY1 - DNSKEY10 DNSKEY10 DNSKEY11 - DNSKEY11 - RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) - RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) - RRSIG11(DNSKEY) - - initial: Initial Version of the zone: DNSKEY 1 is the key signing - key. DNSKEY 10 is used to sign all the data of the zone, the zone - signing key. - new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is - introduced into the key set and all the data in the zone is signed - with DNSKEY 10 and DNSKEY 11. The rollover period will need to - continue until all data from version 0 of the zone has expired - from remote caches. This will take at least the maximum Zone TTL - of version 0 of the zone. - DNSKEY removal: DNSKEY 10 is removed from the zone. All the - signatures from DNSKEY 10 are removed from the zone. The key set, - now only containing DNSKEY 11, is re-signed with DNSKEY 1. - - At every instance, RRSIGs from the previous version of the zone can - be verified with the DNSKEY RRSet from the current version and the - other way around. The data from the current version can be verified - with the data from the previous version of the zone. The duration of - the "new DNSKEY" phase and the period between rollovers should be at - least the Maximum Zone TTL. - - Making sure that the "new DNSKEY" phase lasts until the signature - expiration time of the data in initial version of the zone is - recommended. This way all caches are cleared of the old signatures. - However, this duration could be considerably longer than the Maximum - Zone TTL, making the rollover a lengthy procedure. - - Note that in this example we assumed that the zone was not modified - during the rollover. New data can be introduced in the zone as long - as it is signed with both keys. - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 18] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -4.2.1.3. Pros and Cons of the Schemes - - Pre-publish Key Rollover: This rollover does not involve signing the - zone data twice. Instead, before the actual rollover, the new key - is published in the key set and thus available for cryptanalysis - attacks. A small disadvantage is that this process requires four - steps. Also the pre-publish scheme involves more parental work - when used for KSK rollovers as explained in Section 4.2.3. - Double Signature Zone-signing Key Rollover: The drawback of this - signing scheme is that during the rollover the number of - signatures in your zone doubles, this may be prohibitive if you - have very big zones. An advantage is that it only requires three - steps. - -4.2.2. Key Signing Key Rollovers - - For the rollover of a key signing key the same considerations as for - the rollover of a zone signing key apply. However we can use a - double signature scheme to guarantee that old data (only the apex key - set) in caches can be verified with a new key set and vice versa. - Since only the key set is signed with a KSK, zone size considerations - do not apply. - - - initial new DNSKEY DS change DNSKEY removal - Parent: - SOA0 --------> SOA1 --------> - RRSIGpar(SOA0) --------> RRSIGpar(SOA1) --------> - DS1 --------> DS2 --------> - RRSIGpar(DS) --------> RRSIGpar(DS) --------> - - - Child: - SOA0 SOA1 --------> SOA2 - RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2) - --------> - DNSKEY1 DNSKEY1 --------> DNSKEY2 - DNSKEY2 --------> - DNSKEY10 DNSKEY10 --------> DNSKEY10 - RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY) - RRSIG2 (DNSKEY) --------> - RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) - - Stages of Deployment for Key Signing Key Rollover. - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 19] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - initial: Initial version of the zone. The parental DS points to - DNSKEY1. Before the rollover starts the child will have to verify - what the TTL is of the DS RR that points to DNSKEY1 - it is needed - during the rollover and we refer to the value as TTL_DS. - new DNSKEY: During the "new DNSKEY" phase the zone administrator - generates a second KSK, DNSKEY2. The key is provided to the - parent and the child will have to wait until a new DS RR has been - generated that points to DNSKEY2. After that DS RR has been - published on all servers authoritative for the parent's zone, the - zone administrator has to wait at least TTL_DS to make sure that - the old DS RR has expired from caches. - DS change: The parent replaces DS1 with DS2. - DNSKEY removal: DNSKEY1 has been removed. - - The scenario above puts the responsibility for maintaining a valid - chain of trust with the child. It also is based on the premises that - the parent only has one DS RR (per algorithm) per zone. An - alternative mechanism has been considered. Using an established - trust relation, the interaction can be performed in-band, and the - removal of the keys by the child can possibly be signaled by the - parent. In this mechanism there are periods where there are two DS - RRs at the parent. Since at the moment of writing the protocol for - this interaction has not been developed, further discussion is out of - scope for this document. - -4.2.3. Difference Between ZSK and KSK Rollovers - - Note that KSK rollovers and ZSK rollovers are different in the sense - that a KSK rollover requires interaction with the parent (and - possibly replacing of trust anchors) and the ensuing delay while - waiting for it. - - A zone key rollover can be handled in two different ways: pre-publish - (Section Section 4.2.1.1) and double signature (Section - Section 4.2.1.2). - - As the KSK is used to validate the key set and because the KSK is not - changed during a ZSK rollover, a cache is able to validate the new - key set of the zone. The pre-publish method would also work for a - KSK rollover. The records that are to be pre-published are the - parental DS RRs. The pre-publish method has some drawbacks for KSKs. - We first describe the rollover scheme and then indicate these - drawbacks. - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 20] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - initial new DS new DNSKEY DS/DNSKEY removal - Parent: - SOA0 SOA1 --------> SOA2 - RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2) - DS1 DS1 --------> DS2 - DS2 --------> - RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS) - - - - Child: - SOA0 --------> SOA1 SOA1 - RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1) - --------> - DNSKEY1 --------> DNSKEY2 DNSKEY2 - --------> - DNSKEY10 --------> DNSKEY10 DNSKEY10 - RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY) - RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY) - - Stages of Deployment for a Pre-publish Key Signing Key rollover. - - When the child zone wants to roll it notifies the parent during the - "new DS" phase and submits the new key (or the corresponding DS) to - the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1 - and DNSKEY2 respectively. During the rollover ("new DNSKEY" phase), - which can take place as soon as the new DS set propagated through the - DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that - ("DS/DNSKEY removal" phase) it can notify the parent that the old DS - record can be deleted. - - The drawbacks of this scheme are that during the "new DS" phase the - parent cannot verify the match between the DS2 RR and DNSKEY2 using - the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a - "security lame" key (See Section 4.4.3). Finally the child-parent - interaction consists of two steps. The "double signature" method - only needs one interaction. - -4.2.4. Automated Key Rollovers - - As keys must be renewed periodically, there is some motivation to - automate the rollover process. Consider that: - - o ZSK rollovers are easy to automate as only the child zone is - involved. - o A KSK rollover needs interaction between parent and child. Data - exchange is needed to provide the new keys to the parent, - consequently, this data must be authenticated and integrity must - - - -Kolkman & Gieben Expires September 7, 2006 [Page 21] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - be guaranteed in order to avoid attacks on the rollover. - -4.3. Planning for Emergency Key Rollover - - This section deals with preparation for a possible key compromise. - Our advice is to have a documented procedure ready for when a key - compromise is suspected or confirmed. - - When the private material of one of your keys is compromised it can - be used for as long as a valid trust chain exists. A trust chain - remains intact for: - o as long as a signature over the compromised key in the trust chain - is valid, - o as long as a parental DS RR (and signature) points to the - compromised key, - o as long as the key is anchored in a resolver and is used as a - starting point for validation (this is generally the hardest to - update). - - While a trust chain to your compromised key exists, your name-space - is vulnerable to abuse by anyone who has obtained illegitimate - possession of the key. Zone operators have to make a trade off if - the abuse of the compromised key is worse than having data in caches - that cannot be validated. If the zone operator chooses to break the - trust chain to the compromised key, data in caches signed with this - key cannot be validated. However, if the zone administrator chooses - to take the path of a regular roll-over, the malicious key holder can - spoof data so that it appears to be valid. - -4.3.1. KSK Compromise - - A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable - as long as the compromised KSK is configured as trust anchor or a - parental DS points to it. - - A compromised KSK can be used to sign the key set of an attacker's - zone. That zone could be used to poison the DNS. - - Therefore when the KSK has been compromised, the trust anchor or the - parental DS, should be replaced as soon as possible. It is local - policy whether to break the trust chain during the emergency - rollover. The trust chain would be broken when the compromised KSK - is removed from the child's zone while the parent still has a DS - pointing to the compromised KSK (the assumption is that there is only - one DS at the parent. If there are multiple DSs this does not apply - -- however the chain of trust of this particular key is broken). - - Note that an attacker's zone still uses the compromised KSK and the - - - -Kolkman & Gieben Expires September 7, 2006 [Page 22] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - presence of a parental DS would cause the data in this zone to appear - as valid. Removing the compromised key would cause the attacker's - zone to appear as valid and the child's zone as Bogus. Therefore we - advise not to remove the KSK before the parent has a DS to a new KSK - in place. - -4.3.1.1. Keeping the Chain of Trust Intact - - If we follow this advice the timing of the replacement of the KSK is - somewhat critical. The goal is to remove the compromised KSK as soon - as the new DS RR is available at the parent. And also make sure that - the signature made with a new KSK over the key set with the - compromised KSK in it expires just after the new DS appears at the - parent. Thus removing the old cruft in one swoop. - - The procedure is as follows: - 1. Introduce a new KSK into the key set, keep the compromised KSK in - the key set. - 2. Sign the key set, with a short validity period. The validity - period should expire shortly after the DS is expected to appear - in the parent and the old DSs have expired from caches. - 3. Upload the DS for this new key to the parent. - 4. Follow the procedure of the regular KSK rollover: Wait for the DS - to appear in the authoritative servers and then wait as long as - the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet - and modify/extend the expiration time. - 5. Remove the compromised DNSKEY RR from the zone and re-sign the - key set using your "normal" validity interval. - - An additional danger of a key compromise is that the compromised key - could be used to facilitate a legitimate DNSKEY/DS rollover and/or - nameserver changes at the parent. When that happens the domain may - be in dispute. An authenticated out-of-band and secure notify - mechanism to contact a parent is needed in this case. - - Note that this is only a problem when the DNSKEY and or DS records - are used for authentication at the parent. - -4.3.1.2. Breaking the Chain of Trust - - There are two methods to break the chain of trust. The first method - causes the child zone to appear as 'Bogus' to validating resolvers. - The other causes the the child zone to appear as 'insecure'. These - are described below. - - In the method that causes the child zone to appear as 'Bogus' to - validating resolvers, the child zone replaces the current KSK with a - new one and resigns the key set. Next it sends the DS of the new key - - - -Kolkman & Gieben Expires September 7, 2006 [Page 23] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - to the parent. Only after the parent has placed the new DS in the - zone, the child's chain of trust is repaired. - - An alternative method of breaking the chain of trust is by removing - the DS RRs from the parent zone altogether. As a result the child - zone would become insecure. - -4.3.2. ZSK Compromise - - Primarily because there is no parental interaction required when a - ZSK is compromised, the situation is less severe than with a KSK - compromise. The zone must still be re-signed with a new ZSK as soon - as possible. As this is a local operation and requires no - communication between the parent and child this can be achieved - fairly quickly. However, one has to take into account that just as - with a normal rollover the immediate disappearance of the old - compromised key may lead to verification problems. Also note that as - long as the RRSIG over the compromised ZSK is not expired the zone - may be still at risk. - -4.3.3. Compromises of Keys Anchored in Resolvers - - A key can also be pre-configured in resolvers. For instance, if - DNSSEC is successfully deployed the root key may be pre-configured in - most security aware resolvers. - - If trust-anchor keys are compromised, the resolvers using these keys - should be notified of this fact. Zone administrators may consider - setting up a mailing list to communicate the fact that a SEP key is - about to be rolled over. This communication will of course need to - be authenticated e.g. by using digital signatures. - - End-users faced with the task of updating an anchored key should - always validate the new key. New keys should be authenticated out- - of-band, for example, looking them up on an SSL secured announcement - website. - -4.4. Parental Policies - -4.4.1. Initial Key Exchanges and Parental Policies Considerations - - The initial key exchange is always subject to the policies set by the - parent. When designing a key exchange policy one should take into - account that the authentication and authorization mechanisms used - during a key exchange should be as strong as the authentication and - authorization mechanisms used for the exchange of delegation - information between parent and child. I.e. there is no implicit need - in DNSSEC to make the authentication process stronger than it was in - - - -Kolkman & Gieben Expires September 7, 2006 [Page 24] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - DNS. - - Using the DNS itself as the source for the actual DNSKEY material, - with an out-of-band check on the validity of the DNSKEY, has the - benefit that it reduces the chances of user error. A DNSKEY query - tool can make use of the SEP bit [3] to select the proper key from a - DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is - sent. It can validate the self-signature over a key; thereby - verifying the ownership of the private key material. Fetching the - DNSKEY from the DNS ensures that the chain of trust remains intact - once the parent publishes the DS RR indicating the child is secure. - - Note: the out-of-band verification is still needed when the key- - material is fetched via the DNS. The parent can never be sure - whether the DNSKEY RRs have been spoofed or not. - -4.4.2. Storing Keys or Hashes? - - When designing a registry system one should consider which of the - DNSKEYs and/or the corresponding DSs to store. Since a child zone - might wish to have a DS published using a message digest algorithm - not yet understood by the registry, the registry can't count on being - able to generate the DS record from a raw DNSKEY. Thus, we recommend - that registry systems at least support storing DS records. - - It may also be useful to store DNSKEYs, since having them may help - during troubleshooting and, as long as the child's chosen message - digest is supported, the overhead of generating DS records from them - is minimal. Having an out-of-band mechanism, such as a registry - directory (e.g. Whois), to find out which keys are used to generate - DS Resource Records for specific owners and/or zones may also help - with troubleshooting. - - The storage considerations also relate to the design of the customer - interface and the method by which data is transferred between - registrant and registry; Will the child zone administrator be able to - upload DS RRs with unknown hash algorithms or does the interface only - allow DNSKEYs? In the registry-registrar model one can use the - DNSSEC EPP protocol extension [16] which allows transfer of DS RRs - and optionally DNSKEY RRs. - -4.4.3. Security Lameness - - Security Lameness is defined as what happens when a parent has a DS - RR pointing to a non-existing DNSKEY RR. When this happens the - child's zone may be marked as "Bogus" by verifying DNS clients. - - As part of a comprehensive delegation check the parent could, at key - - - -Kolkman & Gieben Expires September 7, 2006 [Page 25] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - exchange time, verify that the child's key is actually configured in - the DNS. However if a parent does not understand the hashing - algorithm used by child the parental checks are limited to only - comparing the key id. - - Child zones should be very careful removing DNSKEY material, - specifically SEP keys, for which a DS RR exists. - - Once a zone is "security lame", a fix (e.g. removing a DS RR) will - take time to propagate through the DNS. - -4.4.4. DS Signature Validity Period - - Since the DS can be replayed as long as it has a valid signature, a - short signature validity period over the DS minimizes the time a - child is vulnerable in the case of a compromise of the child's - KSK(s). A signature validity period that is too short introduces the - possibility that a zone is marked Bogus in case of a configuration - error in the signer. There may not be enough time to fix the - problems before signatures expire. Something as mundane as operator - unavailability during weekends shows the need for DS signature - validity periods longer than 2 days. We recommend an absolute - minimum for a DS signature validity period of a few days. - - The maximum signature validity period of the DS record depends on how - long child zones are willing to be vulnerable after a key compromise. - On the other hand shortening the DS signature validity interval - increases the operational risk for the parent. Therefore the parent - may have policy to use a signature validity interval that is - considerably longer than the child would hope for. - - A compromise between the operational constraints of the parent and - minimizing damage for the child may result in a DS signature validity - period somewhere between the order of a week to order of months. - - In addition to the signature validity period, which sets a lower - bound on the number of times the zone owner will need to sign the - zone data and which sets an upper bound to the time a child is - vulnerable after key compromise, there is the TTL value on the DS - RRs. Shortening the TTL means that the authoritative servers will - see more queries. But on the other hand, a short TTL lowers the - persistence of DS RRSets in caches thereby increases the speed with - which updated DS RRSets propagate through the DNS. - - -5. IANA Considerations - - This overview document introduces no new IANA considerations. - - - -Kolkman & Gieben Expires September 7, 2006 [Page 26] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -6. Security Considerations - - DNSSEC adds data integrity to the DNS. This document tries to assess - the operational considerations to maintain a stable and secure DNSSEC - service. Not taking into account the 'data propagation' properties - in the DNS will cause validation failures and may make secured zones - unavailable to security aware resolvers. - - -7. Acknowledgments - - Most of the ideas in this draft were the result of collective efforts - during workshops, discussions and try outs. - - At the risk of forgetting individuals who were the original - contributors of the ideas we would like to acknowledge people who - were actively involved in the compilation of this document. In - random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael - Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette - Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger - Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch. - - Some material in this document has been copied from RFC 2541 [12]. - - Mike StJohns designed the key exchange between parent and child - mentioned in the last paragraph of Section 4.2.2 - - Section 4.2.4 was supplied by G. Guette and O. Courtay. - - Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of - the spelling and style issues. - - Kolkman and Gieben take the blame for introducing all miscakes(SIC). - - Kolkman was employed by the RIPE NCC while working on this document. - - -8. References - -8.1. Normative References - - [1] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY - - - -Kolkman & Gieben Expires September 7, 2006 [Page 27] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - -8.2. Informative References - - [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes - (DNS NOTIFY)", RFC 1996, August 1996. - - [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [10] Eastlake, D., "Secure Domain Name System Dynamic Update", - RFC 2137, April 1997. - - [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - - [12] Eastlake, D., "DNS Security Operational Considerations", - RFC 2541, March 1999. - - [13] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [14] Orman, H. and P. Hoffman, "Determining Strengths For Public - Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, - April 2004. - - [15] Eastlake, D., Schiller, J., and S. Crocker, "Randomness - Requirements for Security", BCP 106, RFC 4086, June 2005. - - [16] Hollenbeck, S., "Domain Name System (DNS) Security Extensions - Mapping for the Extensible Provisioning Protocol (EPP)", - RFC 4310, December 2005. - - - -Kolkman & Gieben Expires September 7, 2006 [Page 28] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - [17] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key - Sizes", The Journal of Cryptology 14 (255-293), 2001. - - [18] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and - Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN - (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc., - 1996. - - [19] Rose, S., "NIST DNSSEC workshop notes", June 2001. - - [20] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource - Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt - (work in progress), January 2006. - - [21] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) - Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt - (work in progress), January 2006. - - -Appendix A. Terminology - - In this document there is some jargon used that is defined in other - documents. In most cases we have not copied the text from the - documents defining the terms but given a more elaborate explanation - of the meaning. Note that these explanations should not be seen as - authoritative. - - Anchored Key: A DNSKEY configured in resolvers around the globe. - This key is hard to update, hence the term anchored. - Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked - "Bogus" when a signature of a RRSet does not validate against a - DNSKEY. - Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used - exclusively for signing the apex key set. The fact that a key is - a KSK is only relevant to the signing tool. - Key size: The term 'key size' can be substituted by 'modulus size' - throughout the document. It is mathematically more correct to use - modulus size, but as this is a document directed at operators we - feel more at ease with the term key size. - Private and Public Keys: DNSSEC secures the DNS through the use of - public key cryptography. Public key cryptography is based on the - existence of two (mathematically related) keys, a public key and a - private key. The public keys are published in the DNS by use of - the DNSKEY Resource Record (DNSKEY RR). Private keys should - remain private. - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 29] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - Key Rollover: A key rollover (also called key supercession in some - environments) is the act of replacing one key pair by another at - the end of a key effectivity period. - Secure Entry Point key or SEP Key: A KSK that has a parental DS - record pointing to it or is configured as a trust anchor. - Although not required by the protocol we recommend that the SEP - flag [3] is set on these keys. - Self-signature: This is only applies to signatures over DNSKEYs; a - signature made with DNSKEY x, over DNSKEY x is called a self- - signature. Note: without further information self-signatures - convey no trust, they are useful to check the authenticity of the - DNSKEY, i.e. they can be used as a hash. - Singing the Zone File: The term used for the event where an - administrator joyfully signs its zone file while producing melodic - sound patterns. - Signer: The system that has access to the private key material and - signs the Resource Record sets in a zone. A signer may be - configured to sign only parts of the zone e.g. only those RRSets - for which existing signatures are about to expire. - Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is - used for signing all data in a zone. The fact that a key is a ZSK - is only relevant to the signing tool. - Zone Administrator: The 'role' that is responsible for signing a zone - and publishing it on the primary authoritative server. - - -Appendix B. Zone Signing Key Rollover Howto - - Using the pre-published signature scheme and the most conservative - method to assure oneself that data does not live in caches, here - follows the "HOWTO". - Step 0: The preparation: Create two keys and publish both in your key - set. Mark one of the keys as "active" and the other as - "published". Use the "active" key for signing your zone data. - Store the private part of the "published" key, preferably off- - line. - The protocol does not provide for attributes to mark a key as - active or published. This is something you have to do on your - own, through the use of a notebook or key management tool. - Step 1: Determine expiration: At the beginning of the rollover make a - note of the highest expiration time of signatures in your zone - file created with the current key marked as "active". - Wait until the expiration time marked in Step 1 has passed - Step 2: Then start using the key that was marked as "published" to - sign your data i.e. mark it as "active". Stop using the key that - was marked as "active", mark it as "rolled". - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 30] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - Step 3: It is safe to engage in a new rollover (Step 1) after at - least one "signature validity period". - - -Appendix C. Typographic Conventions - - The following typographic conventions are used in this document: - Key notation: A key is denoted by DNSKEYx, where x is a number or an - identifier, x could be thought of as the key id. - RRSet notations: RRs are only denoted by the type. All other - information - owner, class, rdata and TTL - is left out. Thus: - "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a - list of RRs. A example of this would be: "A1, A2", specifying the - RRSet containing two "A" records. This could again be abbreviated - to just "A". - Signature notation: Signatures are denoted as RRSIGx(RRSet), which - means that RRSet is signed with DNSKEYx. - Zone representation: Using the above notation we have simplified the - representation of a signed zone by leaving out all unnecessary - details such as the names and by representing all data by "SOAx" - SOA representation: SOAs are represented as SOAx, where x is the - serial number. - Using this notation the following signed zone: - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 31] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - example.net. 86400 IN SOA ns.example.net. bert.example.net. ( - 2006022100 ; serial - 86400 ; refresh ( 24 hours) - 7200 ; retry ( 2 hours) - 3600000 ; expire (1000 hours) - 28800 ) ; minimum ( 8 hours) - 86400 RRSIG SOA 5 2 86400 20130522213204 ( - 20130422213204 14 example.net. - cmL62SI6iAX46xGNQAdQ... ) - 86400 NS a.iana-servers.net. - 86400 NS b.iana-servers.net. - 86400 RRSIG NS 5 2 86400 20130507213204 ( - 20130407213204 14 example.net. - SO5epiJei19AjXoUpFnQ ... ) - 86400 DNSKEY 256 3 5 ( - EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14 - 86400 DNSKEY 257 3 5 ( - gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15 - 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( - 20130422213204 14 example.net. - J4zCe8QX4tXVGjV4e1r9... ) - 86400 RRSIG DNSKEY 5 2 86400 20130522213204 ( - 20130422213204 15 example.net. - keVDCOpsSeDReyV6O... ) - 86400 RRSIG NSEC 5 2 86400 20130507213204 ( - 20130407213204 14 example.net. - obj3HEp1GjnmhRjX... ) - a.example.net. 86400 IN TXT "A label" - 86400 RRSIG TXT 5 3 86400 20130507213204 ( - 20130407213204 14 example.net. - IkDMlRdYLmXH7QJnuF3v... ) - 86400 NSEC b.example.com. TXT RRSIG NSEC - 86400 RRSIG NSEC 5 3 86400 20130507213204 ( - 20130407213204 14 example.net. - bZMjoZ3bHjnEz0nIsPMM... ) - ... - - is reduced to the following representation: - - SOA2006022100 - RRSIG14(SOA2006022100) - DNSKEY14 - DNSKEY15 - - RRSIG14(KEY) - RRSIG15(KEY) - - The rest of the zone data has the same signature as the SOA record, - - - -Kolkman & Gieben Expires September 7, 2006 [Page 32] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - i.e a RRSIG created with DNSKEY 14. - - -Appendix D. Document Details and Changes - - This section is to be removed by the RFC editor if and when the - document is published. - - $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14 - 2005/03/21 15:51:41 dnssec Exp $ - -D.1. draft-ietf-dnsop-dnssec-operational-practices-00 - - Submission as working group document. This document is a modified - and updated version of draft-kolkman-dnssec-operational-practices-00. - -D.2. draft-ietf-dnsop-dnssec-operational-practices-01 - - changed the definition of "Bogus" to reflect the one in the protocol - draft. - - Bad to Bogus - - Style and spelling corrections - - KSK - SEP mapping made explicit. - - Updates from Sam Weiler added - -D.3. draft-ietf-dnsop-dnssec-operational-practices-02 - - Style and errors corrected. - - Added Automatic rollover requirements from I-D.ietf-dnsop-key- - rollover-requirements. - -D.4. draft-ietf-dnsop-dnssec-operational-practices-03 - - Added the definition of Key effectivity period and used that term - instead of Key validity period. - - Modified the order of the sections, based on a suggestion by Rip - Loomis. - - Included parts from RFC 2541 [12]. Most of its ground was already - covered. This document obsoletes RFC 2541 [12]. Section 3.1.2 - deserves some review as it in contrast to RFC 2541 does _not_ give - recomendations about root-zone keys. - - - -Kolkman & Gieben Expires September 7, 2006 [Page 33] - -Internet-Draft DNSSEC Operational Practices March 2006 - - - added a paragraph to Section 4.4.4 - -D.5. draft-ietf-dnsop-dnssec-operational-practices-04 - - Somewhat more details added about the pre-publish KSK rollover. Also - moved that subsection down a bit. - - Editorial and content nits that came in during wg last call were - fixed. - -D.6. draft-ietf-dnsop-dnssec-operational-practices-05 - - Applied some another set of comments that came in _after_ the the - WGLC. - - Applied comments from Hilarie Orman and made a referece to RFC 3766. - Deleted of a lot of key length discussion and took over the - recommendations from RFC 3766. - - Reworked all the heading of the rollover figures - -D.7. draft-ietf-dnsop-dnssec-operational-practices-06 - - One comment from Scott Rose applied. - - Marcos Sanz gave a lots of editorial nits. Almost all are - incorporated. - -D.8. draft-ietf-dnsop-dnssec-operational-practices-07 - - Peter Koch's comments applied. - - SHA-1/SHA-256 remarks added - -D.9. draft-ietf-dnsop-dnssec-operational-practices-08 - - IESG comments applied. Added headers and some captions to the tables - and applied all the nits. - - IESG DISCUSS comments applied - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 34] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -Authors' Addresses - - Olaf M. Kolkman - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - The Netherlands - - Email: olaf@nlnetlabs.nl - URI: http://www.nlnetlabs.nl - - - Miek Gieben - NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA - The Netherlands - - Email: miek@nlnetlabs.nl - URI: http://www.nlnetlabs.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 35] - -Internet-Draft DNSSEC Operational Practices March 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Kolkman & Gieben Expires September 7, 2006 [Page 36] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt deleted file mode 100644 index bcd0d14..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt +++ /dev/null @@ -1,396 +0,0 @@ - - - - - - -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/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt deleted file mode 100644 index bf2afcd..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt +++ /dev/null @@ -1,1848 +0,0 @@ - - - -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/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt deleted file mode 100644 index 1276f9f..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt +++ /dev/null @@ -1,1682 +0,0 @@ - - - - -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/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt deleted file mode 100644 index b2e2341..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt +++ /dev/null @@ -1,300 +0,0 @@ -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/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt deleted file mode 100644 index 6bece56..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt +++ /dev/null @@ -1,389 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt deleted file mode 100644 index 63fe2de..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt +++ /dev/null @@ -1,480 +0,0 @@ - - - - - - - DNSOP Working Group Paul Vixie, ISC - INTERNET-DRAFT Akira Kato, WIDE - <draft-ietf-dnsop-respsize-02.txt> July 2005 - - DNS 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 (2005). All Rights Reserved. - - - - - Abstract - - With a mandated default minimum maximum message size of 512 octets, - the DNS protocol presents some special problems for zones wishing to - expose a moderate or high number of authority servers (NS RRs). This - document explains the operational issues caused by, or related to - this response size limit. - - - - - - - Expires December 2005 [Page 1] - - INTERNET-DRAFT July 2005 RESPSIZE - - - 1 - Introduction and Overview - - 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 - octets. Even though this limitation was due to the required minimum UDP - reassembly limit for IPv4, it is a hard DNS protocol limit and is not - implicitly relaxed by changes in transport, for example to IPv6. - - 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger - responses by mutual agreement of the requestor and responder. However, - deployment of EDNS0 cannot be expected to reach every Internet resolver - in the short or medium term. The 512 octet message size limit remains - in practical effect at this time. - - 1.3. Since DNS responses include a copy of the request, the space - available for response data is somewhat less than the full 512 octets. - For negative responses, there is rarely a space constraint. For - positive and delegation responses, though, every octet must be carefully - and sparingly allocated. This document specifically addresses - delegation response sizes. - - 2 - Delegation Details - - 2.1. A delegation response will include the following elements: - - Header Section: fixed length (12 octets) - Question Section: original query (name, class, type) - Answer Section: (empty) - Authority Section: NS RRset (nameserver names) - Additional Section: A and AAAA RRsets (nameserver addresses) - - 2.2. If the total response size would exceed 512 octets, and if the data - that would not fit belonged in the question, answer, or authority - section, then the TC bit will be set (indicating truncation) which may - cause the requestor to retry using TCP, depending on what information - was desired and what information was omitted. 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 protocol requirement that UDP be attempted - before falling back to TCP.) - - 2.3. RRsets are never sent partially unless truncation occurs, in which - case the final apparent RRset in the final nonempty section must be - considered "possibly damaged". With or without truncation, the glue - present in the additional data section should be considered "possibly - incomplete", and requestors should be prepared to re-query for any - damaged or missing RRsets. For multi-transport name or mail services, - - - - Expires December 2005 [Page 2] - - INTERNET-DRAFT July 2005 RESPSIZE - - - this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A) - RRset is present. - - 2.4. DNS label compression allows a domain name to be instantiated only - once per DNS message, and then referenced with a two-octet "pointer" - from other locations in that same DNS message. If all nameserver names - in a message are similar (for example, all ending in ".ROOT- - SERVERS.NET"), then more space will be available for uncompressable data - (such as nameserver addresses). - - 2.5. The query name can be as long as 255 characters of presentation - data, which can be up to 256 octets of network data. In this worst case - scenario, the question section will be 260 octets in size, which would - leave only 240 octets for the authority and additional sections (after - deducting 12 octets for the fixed length header.) - - 2.6. Average and maximum question section sizes can be predicted by the - zone owner, since they will know what names actually exist, and can - measure which ones are queried for most often. For cost and performance - reasons, the majority of requests should be satisfied without truncation - or TCP retry. - - 2.7. Requestors who deliberately send large queries to force truncation - are only increasing their own costs, and cannot effectively attack the - resources of an authority server since the requestor would have to retry - using TCP to complete the attack. An attack that always used TCP would - have a lower cost. - - 2.8. The minimum useful number of address records is two, since with - only one address, the probability that it would refer to an unreachable - server is too high. Truncation which occurs after two address records - have been added to the additional data section is therefore less - operationally significant than truncation which occurs earlier. - - 2.9. The best case is no truncation. This is because many requestors - will retry using TCP by reflex, or will automatically re-query for - RRsets that are "possibly truncated", without considering whether the - omitted data was actually necessary. - - 2.10. Each added NS RR for a zone will add a minimum of between 16 and - 44 octets to every untruncated referral or negative response from the - zone's authority servers (16 octets for an NS RR, 16 octets for an A RR, - and 28 octets for an AAAA RR), in addition to whatever space is taken by - the nameserver name (NS NSDNAME and A/AAAA owner name). - - - - - Expires December 2005 [Page 3] - - INTERNET-DRAFT July 2005 RESPSIZE - - - 3 - Analysis - - 3.1. An instrumented protocol trace of a best case delegation response - follows. Note that 13 servers are named, and 13 addresses are given. - This query was artificially designed to exactly reach the 512 octet - limit. - - ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 - ;; QUERY SECTION: - ;; [23456789.123456789.123456789.\ - 123456789.123456789.123456789.com A IN] ;; @80 - - ;; AUTHORITY SECTION: - com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 - com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 - com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 - com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 - com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 - com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 - com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 - com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 - com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 - com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 - com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 - com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 - com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 - - ;; ADDITIONAL SECTION: - A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 - B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 - C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 - D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 - E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 - F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 - G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 - H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 - I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 - J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 - K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 - L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 - M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 - - ;; MSG SIZE sent: 80 rcvd: 512 - - - - - - Expires December 2005 [Page 4] - - INTERNET-DRAFT July 2005 RESPSIZE - - - 3.2. For longer query names, the number of address records supplied will - be lower. Furthermore, it is only by using a common parent name (which - is GTLD-SERVERS.NET in this example) that all 13 addresses are able to - fit. The following output from a response simulator demonstrates these - properties: - - % perl respsize.pl 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): - if only A is considered: # of A is 4 (green) - if A and AAAA are condered: # of A+AAAA is 3 (yellow) - if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow) - For average size query (64 byte): - if only A is considered: # of A is 4 (green) - if A and AAAA are condered: # of A+AAAA is 4 (green) - if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green) - - % 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): - if only A is considered: # of A is 4 (green) - if A and AAAA are condered: # of A+AAAA is 3 (yellow) - if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow) - For average size query (64 byte): - if only A is considered: # of A is 4 (green) - if A and AAAA are condered: # of A+AAAA is 4 (green) - if prefer_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 - "orange" if two or more could fit, or "red" if fewer than two could fit. - It's clear that without a common parent for nameserver names, much space - would be lost. 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. - - - - - Expires December 2005 [Page 5] - - INTERNET-DRAFT July 2005 RESPSIZE - - - We're assuming an average query name size of 64 since that is the - typical average maximum size seen in trace data at the time of this - writing. If Internationalized Domain Name (IDN) or any other technology - which results in larger query names be deployed significantly in advance - of EDNS, then new measurements and new estimates will have to be made. - - 4 - Conclusions - - 4.1. The current practice of giving all nameserver names a common parent - (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS - responses and allows for more nameservers to be enumerated than would - otherwise be possible. (Note that in this case it is wise to serve the - common parent domain's zone from the same servers that are named within - it, in order to limit external dependencies when all your eggs are in a - single basket.) - - 4.2. Thirteen (13) seems to be the effective maximum number of - nameserver names usable traditional (non-extended) DNS, assuming a - common parent domain name, and given that response truncation is - undesirable as an average case, and assuming mostly IPv4-only - reachability (only A RRs exist, not AAAA RRs). - - 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a - prototypical delegation that currently contains thirteen (13) IPv4 - nameserver addresses (A RRs) for thirteen (13) nameserver names under a - common parent, would not have a significant negative operational impact - on the domain name system. - - 5 - Source Code - - #!/usr/bin/perl - # - # SYNOPSIS - # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ... - # if all queries are assumed to have zone suffux, such as "jp" in - # JP TLD servers, specify it in -z option - # - use strict; - use Getopt::Std; - 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; - - - - - Expires December 2005 [Page 6] - - INTERNET-DRAFT July 2005 RESPSIZE - - - 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); - $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 "if only A is considered: "; - printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns); - printf "if A and AAAA are condered: "; - printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns); - - - - Expires December 2005 [Page 7] - - INTERNET-DRAFT July 2005 RESPSIZE - - - printf "if prefer_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; - } - - Security Considerations - - The recommendations contained in this document have no known security - implications. - - IANA Considerations - - This document does not call for changes or additions to any IANA - registry. - - IPR Statement - - Copyright (C) The Internet Society (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. - - - - - - Expires December 2005 [Page 8] - - INTERNET-DRAFT July 2005 RESPSIZE - - - Authors' Addresses - - Paul Vixie - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - vixie@isc.org - - Akira Kato - University of Tokyo, Information Technology Center - 2-11-16 Yayoi Bunkyo - Tokyo 113-8658, JAPAN - +81 3 5841 2750 - kato@wide.ad.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires December 2005 [Page 9] -
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt deleted file mode 100644 index c6ec7e4..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt +++ /dev/null @@ -1,618 +0,0 @@ - - - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: September 6, 2006 D. Conrad - Nominum, Inc. - March 5, 2006 - - - Requirements for a Mechanism Identifying a Name Server Instance - draft-ietf-dnsop-serverid-06 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 6, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid for - administrators. Existing ad hoc mechanisms for addressing this need - - - -Woolf & Conrad Expires September 6, 2006 [Page 1] - -Internet-Draft Serverid March 2006 - - - have some shortcomings, not the least of which is the lack of prior - analysis of exactly how such a mechanism should be designed and - deployed. This document describes the existing convention used in - some widely deployed implementations of the DNS protocol, including - advantages and disadvantages, and discusses some attributes of an - improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 2] - -Internet-Draft Serverid March 2006 - - -1. Introduction and Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. This is most obviously useful for authoritative - nameservers in the attempt to diagnose the source or prevalence of - inaccurate data, but can also conceivably be useful for caching - resolvers in similar and other situations. Furthermore, the ability - to identify which server is responding to a query has become more - useful as DNS has become more critical to more Internet users, and as - network and server deployment topologies have become more complex. - - The traditional means for determining which of several possible - servers is answering a query has traditionally been based on the use - of the server's IP address as a unique identifier. However, the - modern Internet has seen the deployment of various load balancing, - fault-tolerance, or attack-resistance schemes such as shared use of - unicast IP addresses as documented in [RFC3258]. An unfortunate side - effect of these schemes has been to make the use of IP addresses as - identifiers somewhat problematic. Specifically, a dedicated DNS - query may not go to the same server as answered a previous query, - even though sent to the same IP address. Non-DNS methods such as - ICMP ping, TCP connections, or non-DNS UDP packets (such as those - generated by tools like "traceroute"), etc., may well be even less - certain to reach the same server as the one which receives the DNS - queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the possibly-non- - unique "server that answered the query I sent to IP address XXX". - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 3] - -Internet-Draft Serverid March 2006 - - -2. Existing Conventions - - For some time, the commonly deployed Berkeley Internet Name Domain - implementation of the DNS protocol suite from the Internet Systems - Consortium [BIND] has supported a way of identifying a particular - server via the use of a standards-compliant, if somewhat unusual, DNS - query. Specifically, a query to a recent BIND server for a TXT - resource record in class 3 (CHAOS) for the domain name - "HOSTNAME.BIND." will return a string that can be configured by the - name server administrator to provide a unique identifier for the - responding server. (The value defaults to the result of a - gethostname() call). This mechanism, which is an extension of the - BIND convention of using CHAOS class TXT RR queries to sub-domains of - the "BIND." domain for version information, has been copied by - several name server vendors. - - A refinement to the BIND-based mechanism, which dropped the - implementation-specific string, replaces ".BIND" with ".SERVER". - Thus the query string to learn the unique name of a server may be - queried as "ID.SERVER". - - (For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a CHAOS TXT RR for this name will return an - administratively defined string which defaults to the version of the - server responding. This is, however, not generally implemented by - other vendors.) - -2.1. Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - - 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is - within the DNS protocol itself. An identification mechanism that - relies on the DNS protocol is more likely to be successful - (although not guaranteed) in going to the same system as a - "normal" DNS query. - - 2. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it is likely to - reach the same server over a path subject to the same routing, - resource, and security policy as the query, without any special - exceptions to site security policy. - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 4] - -Internet-Draft Serverid March 2006 - - - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - - 4. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - - 5. Hypothetically, since it's an ordinary DNS record and the - relevant DNSSEC RRs are class independent, the id.server response - RR could be signed, which has the advantages described in - [RFC4033]. - -2.2. Disadvantages - - At the same time, there are some serious drawbacks to the CHAOS/TXT - query mechanism that argue against standardizing it as it currently - operates. - - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - purpose is a good use of the namespace or of implementation - effort. - - 3. The initial and still common form, using .BIND, is implementation - specific. BIND is one DNS implementation. At the time of this - writing, it is probably the most prevalent for authoritative - servers. This does not justify standardizing on its ad hoc - solution to a problem shared across many operators and - implementors. Meanwhile, the proposed refinement changes the - string but preserves the ad hoc CHAOS/TXT mechanism. - - 4. There is no convention or shared understanding of what - information an answer to such a query for a server identity could - or should include, including a possible encoding or - authentication mechanism. - - The first of the listed disadvantages may be technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 5] - -Internet-Draft Serverid March 2006 - - -2.3. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - - 1. The mechanism adopted must be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It should - also permit a separate, dedicated query for the server's - identifying information. But it should preserve the ability of - the CHAOS/TXT query-based mechanism to work through firewalls and - in other situations where only DNS can be relied upon to reach - the server of interest. - - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - and top level domain in the authoritative server (or the querying - tool) to be useful. - - 3. Support for the identification functionality should be easy to - implement and easy to enable. It must be easy to disable and - should lend itself to access controls on who can query for it. - - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be non- - public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - - 5. It should be possible to authenticate the received data by some - mechanism analogous to those provided by DNSSEC. In this - context, the need could be met by including encryption options in - the specification of a new mechanism. - - 6. The identification mechanism should not be implementation- - specific. - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 6] - -Internet-Draft Serverid March 2006 - - -3. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. A proposed extension, specified and adopted by normal IETF - process, is described in [NSID], including relevant IANA action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 7] - -Internet-Draft Serverid March 2006 - - -4. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet can be - seen as information leakage and thus a security risk. This motivates - the suggestion above that a new mechanism for server identification - allow the administrator to disable the functionality altogether or - partially restrict availability of the data. It also suggests that - the serverid data should not be readily correlated with a hostname or - unicast IP address that may be considered private to the nameserver - operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - Both authentication and confidentiality of serverid data are - potentially of interest to administrators-- that is, operators may - wish to make serverid data available and reliable to themselves and - their chosen associates only. This would imply both an ability to - authenticate it to themselves and keep it private from arbitrary - other parties. This led to Characteristics 4 and 5 of an improved - solution. - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 8] - -Internet-Draft Serverid March 2006 - - -5. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest version - takes a significantly different direction from previous versions, - owing to discussion among contributors to the DNSOP working group and - others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam - Weiler, and Rob Austein. - -6. References - - [1] Mockapetris, P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 0013, November 1987. - - [2] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, STD 0013, November 1987. - - [3] Hardie, T., "Distributing Authoritative Name Servers via Shared - Unicast Addresses", RFC 3258, April 2002. - - [4] ISC, "BIND 9 Configuration Reference". - - [5] Austein, S., "DNS Name Server Identifier Option (NSID)", - Internet Drafts http://www.ietf.org/internet-drafts/ - draft-ietf-dnsext-nsid-01.txt, January 2006. - - [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 9] - -Internet-Draft Serverid March 2006 - - -Authors' Addresses - - Suzanne Woolf - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 423-1333 - Email: woolf@isc.org - URI: http://www.isc.org/ - - - David Conrad - Nominum, Inc. - 2385 Bay Road - Redwood City, CA 94063 - US - - Phone: +1 1 650 381 6003 - Email: david.conrad@nominum.com - URI: http://www.nominum.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires September 6, 2006 [Page 10] - -Internet-Draft Serverid March 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires September 6, 2006 [Page 11] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt deleted file mode 100644 index 3353b3b..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt +++ /dev/null @@ -1,1588 +0,0 @@ - - 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/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt deleted file mode 100644 index 2d5c87e..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt +++ /dev/null @@ -1,1200 +0,0 @@ - - - - - - -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/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt b/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt deleted file mode 100644 index a272d81..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt +++ /dev/null @@ -1,614 +0,0 @@ -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/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt deleted file mode 100644 index 3578d2a..0000000 --- a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt +++ /dev/null @@ -1,519 +0,0 @@ - -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/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt b/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt deleted file mode 100644 index d857cd9..0000000 --- a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt +++ /dev/null @@ -1,295 +0,0 @@ - - - -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/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt deleted file mode 100644 index f9eaf26..0000000 --- a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt +++ /dev/null @@ -1,1830 +0,0 @@ - - - - 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/contrib/bind9/doc/draft/update b/contrib/bind9/doc/draft/update deleted file mode 100644 index 6ac2090..0000000 --- a/contrib/bind9/doc/draft/update +++ /dev/null @@ -1,46 +0,0 @@ -#!/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 |
