diff options
Diffstat (limited to 'contrib/bind9/doc/draft')
35 files changed, 0 insertions, 32803 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 1030e5782ef90..0000000000000 --- 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 fffa8a5f20b3d..0000000000000 --- 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 4a01d91b9a8be..0000000000000 --- 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 7b5e8cc4455ba..0000000000000 --- 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 224e7ad1697e2..0000000000000 --- 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-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt deleted file mode 100644 index f0ce70ab1c997..0000000000000 --- 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-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt deleted file mode 100644 index 09776618f2ae3..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt +++ /dev/null @@ -1,561 +0,0 @@ - - -DNSEXT M. Stapp -Internet-Draft Cisco Systems, Inc. -Expires: January 14, 2005 T. Lemon - A. Gustafsson - Nominum, Inc. - July 16, 2004 - - - A DNS RR for Encoding DHCP Information (DHCID RR) - <draft-ietf-dnsext-dhcid-rr-08.txt> - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 14, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - It is possible for multiple DHCP clients to attempt to update the - same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or - the clients themselves perform the DNS updates, conflicts can arise. - To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] - proposes storing client identifiers in the DNS to unambiguously - - - -Stapp, et al. Expires January 14, 2005 [Page 1] - -Internet-Draft The DHCID RR July 2004 - - - associate domain names with the DHCP clients to which they refer. - This memo defines a distinct RR type for this purpose for use by DHCP - clients and servers, the "DHCID" RR. - -Table of Contents - - 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 4 - 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . 4 - 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . 4 - 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . 4 - 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 6 - 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 6 - 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 - Intellectual Property and Copyright Statements . . . . . . . . 10 - - - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires January 14, 2005 [Page 2] - -Internet-Draft The DHCID RR July 2004 - - -1. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [2]. - -2. Introduction - - A set of procedures to allow DHCP [7] clients and servers to - automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed - in "Resolution of DNS Name Conflicts" [1]. - - Conflicts can arise if multiple DHCP clients wish to use the same DNS - name. To resolve such conflicts, "Resolution of DNS Name Conflicts" - [1] proposes storing client identifiers in the DNS to unambiguously - associate domain names with the DHCP clients using them. In the - interest of clarity, it is preferable for this DHCP information to - use a distinct RR type. This memo defines a distinct RR for this - purpose for use by DHCP clients or servers, the "DHCID" RR. - - In order to avoid exposing potentially sensitive identifying - information, the data stored is the result of a one-way MD5 [5] hash - computation. The hash includes information from the DHCP client's - REQUEST message as well as the domain name itself, so that the data - stored in the DHCID RR will be dependent on both the client - identification used in the DHCP protocol interaction and the domain - name. This means that the DHCID RDATA will vary if a single client - is associated over time with more than one name. This makes it - difficult to 'track' a client as it is associated with various domain - names. - - The MD5 hash algorithm has been shown to be weaker than the SHA-1 - algorithm; it could therefore be argued that SHA-1 is a better - choice. However, SHA-1 is significantly slower than MD5. A - successful attack of MD5's weakness does not reveal the original data - that was used to generate the signature, but rather provides a new - set of input data that will produce the same signature. Because we - are using the MD5 hash to conceal the original data, the fact that an - attacker could produce a different plaintext resulting in the same - MD5 output is not significant concern. - -3. The DHCID RR - - The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The - DHCID RR is only defined in the IN class. DHCID RRs cause no - additional section processing. The DHCID RR is not a singleton type. - - - - - -Stapp, et al. Expires January 14, 2005 [Page 3] - -Internet-Draft The DHCID RR July 2004 - - -3.1 DHCID RDATA format - - The RDATA section of a DHCID RR in transmission contains RDLENGTH - bytes of binary data. The format of this data and its interpretation - by DHCP servers and clients are described below. - - DNS software should consider the RDATA section to be opaque. DHCP - clients or servers use the DHCID RR to associate a DHCP client's - identity with a DNS name, so that multiple DHCP clients and servers - may deterministically perform dynamic DNS updates to the same zone. - From the updater's perspective, the DHCID resource record RDATA - consists of a 16-bit identifier type, in network byte order, followed - by one or more bytes representing the actual identifier: - - < 16 bits > DHCP identifier used - < n bytes > MD5 digest - - -3.2 DHCID Presentation Format - - In DNS master files, the RDATA is represented as a single block in - base 64 encoding identical to that used for representing binary data - in RFC 2535 [8]. The data may be divided up into any number of white - space separated substrings, down to single base 64 digits, which are - concatenated to form the complete RDATA. These substrings can span - lines using the standard parentheses. - -3.3 The DHCID RR Type Codes - - The DHCID RR Type Code specifies what data from the DHCP client's - request was used as input into the hash function. The type codes are - defined in a registry maintained by IANA, as specified in Section 7. - The initial list of assigned values for the type code is: - - 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7]. - 0x0001 = The data portion from a DHCPv4 client's Client Identifier - option [9]. - 0x0002 = The client's DUID (i.e., the data portion of a DHCPv6 - client's Client Identifier option [10] or the DUID field from a - DHCPv4 client's Client Identifier option [12]). - - 0x0003 - 0xfffe = Available to be assigned by IANA. - - 0xffff = RESERVED - -3.4 Computation of the RDATA - - The DHCID RDATA is formed by concatenating the two type bytes with - - - -Stapp, et al. Expires January 14, 2005 [Page 4] - -Internet-Draft The DHCID RR July 2004 - - - some variable-length identifying data. - - < type > < data > - - The RDATA for all type codes other than 0xffff, which is reserved for - future expansion, is formed by concatenating the two type bytes and a - 16-byte MD5 hash value. The input to the hash function is defined to - be: - - data = MD5(< identifier > < FQDN >) - - The FQDN is represented in the buffer in unambiguous canonical form - as described in RFC 2535 [8], section 8.1. The type code and the - identifier are related as specified in Section 3.3: the type code - describes the source of the identifier. - - When the updater is using the client's link-layer address as the - identifier, the first two bytes of the DHCID RDATA MUST be zero. To - generate the rest of the resource record, the updater computes a - one-way hash using the MD5 algorithm across a buffer containing the - client's network hardware type, link-layer address, and the FQDN - data. Specifically, the first byte of the buffer contains the - network hardware type as it appeared in the DHCP 'htype' field of the - client's DHCPREQUEST message. All of the significant bytes of the - chaddr field in the client's DHCPREQUEST message follow, in the same - order in which the bytes appear in the DHCPREQUEST message. The - number of significant bytes in the 'chaddr' field is specified in the - 'hlen' field of the DHCPREQUEST message. The FQDN data, as specified - above, follows. - - When the updater is using the DHCPv4 Client Identifier option sent by - the client in its DHCPREQUEST message, the first two bytes of the - DHCID RR MUST be 0x0001, in network byte order. The rest of the - DHCID RR MUST contain the results of computing an MD5 hash across the - payload of the option, followed by the FQDN. The payload of the - option consists of the bytes of the option following the option code - and length. - - When the updater is using the DHCPv6 DUID sent by the client in its - REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002, - in network byte order. The rest of the DHCID RR MUST contain the - results of computing an MD5 hash across the payload of the option, - followed by the FQDN. The payload of the option consists of the - bytes of the option following the option code and length. - -3.5 Examples - - - - - -Stapp, et al. Expires January 14, 2005 [Page 5] - -Internet-Draft The DHCID RR July 2004 - - -3.5.1 Example 1 - - A DHCP server allocating the IPv4 address 10.0.0.1 to a client with - Ethernet MAC address 01:02:03:04:05:06 using domain name - "client.example.com" uses the client's link-layer address to identify - the client. The DHCID RDATA is composed by setting the two type - bytes to zero, and performing an MD5 hash computation across a buffer - containing the Ethernet MAC type byte, 0x01, the six bytes of MAC - address, and the domain name (represented as specified in Section - 3.4). - - client.example.com. A 10.0.0.1 - client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU - - -3.5.2 Example 2 - - A DHCP server allocates the IPv4 address 10.0.12.99 to a client which - included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c - in its DHCP request. The server updates the name "chi.example.com" - on the client's behalf, and uses the DHCP client identifier option - data as input in forming a DHCID RR. The DHCID RDATA is formed by - setting the two type bytes to the value 0x0001, and performing an MD5 - hash computation across a buffer containing the seven bytes from the - client-id option and the FQDN (represented as specified in Section - 3.4). - - chi.example.com. A 10.0.12.99 - chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 - - -4. Use of the DHCID RR - - This RR MUST NOT be used for any purpose other than that detailed in - "Resolution of DNS Name Conflicts" [1]. Although this RR contains - data that is opaque to DNS servers, the data must be consistent - across all entities that update and interpret this record. - Therefore, new data formats may only be defined through actions of - the DHC Working Group, as a result of revising [1]. - -5. Updater Behavior - - The data in the DHCID RR allows updaters to determine whether more - than one DHCP client desires to use a particular FQDN. This allows - site administrators to establish policy about DNS updates. The DHCID - RR does not establish any policy itself. - - Updaters use data from a DHCP client's request and the domain name - - - -Stapp, et al. Expires January 14, 2005 [Page 6] - -Internet-Draft The DHCID RR July 2004 - - - that the client desires to use to compute a client identity hash, and - then compare that hash to the data in any DHCID RRs on the name that - they wish to associate with the client's IP address. If an updater - discovers DHCID RRs whose RDATA does not match the client identity - that they have computed, the updater SHOULD conclude that a different - client is currently associated with the name in question. The - updater SHOULD then proceed according to the site's administrative - policy. That policy might dictate that a different name be selected, - or it might permit the updater to continue. - -6. Security Considerations - - The DHCID record as such does not introduce any new security problems - into the DNS. In order to avoid exposing private information about - DHCP clients to public scrutiny, a one-way hash is used to obscure - all client information. In order to make it difficult to 'track' a - client by examining the names associated with a particular hash - value, the FQDN is included in the hash computation. Thus, the RDATA - is dependent on both the DHCP client identification data and on each - FQDN associated with the client. - - Administrators should be wary of permitting unsecured DNS updates to - zones which are exposed to the global Internet. Both DHCP clients - and servers SHOULD use some form of update authentication (e.g., TSIG - [11]) when performing DNS updates. - -7. IANA Considerations - - IANA is requested to allocate an RR type number for the DHCID record - type. - - This specification defines a new number-space for the 16-bit type - codes associated with the DHCID RR. IANA is requested to establish a - registry of the values for this number-space. - - Three initial values are assigned in Section 3.3, and the value - 0xFFFF is reserved for future use. New DHCID RR type codes are - tentatively assigned after the specification for the associated type - code, published as an Internet Draft, has received expert review by a - designated expert. The final assignment of DHCID RR type codes is - through Standards Action, as defined in RFC 2434 [6]. - -8. Acknowledgements - - Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz, and - Ralph Droms for their review and suggestions. - - - - - -Stapp, et al. Expires January 14, 2005 [Page 7] - -Internet-Draft The DHCID RR July 2004 - - -9. References - -9.1 Normative References - - [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among - DHCP Clients (draft-ietf-dhc-dns-resolution-*)", July 2004. - - [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [3] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [4] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April - 1992. - - [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - -9.2 Informative References - - [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - - [8] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor - Extensions", RFC 2132, March 1997. - - [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. - Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers - for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. - - - - - - - - -Stapp, et al. Expires January 14, 2005 [Page 8] - -Internet-Draft The DHCID RR July 2004 - - -Authors' Addresses - - Mark Stapp - Cisco Systems, Inc. - 1414 Massachusetts Ave. - Boxborough, MA 01719 - USA - - Phone: 978.936.1535 - EMail: mjs@cisco.com - - - Ted Lemon - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - EMail: mellon@nominum.com - - - Andreas Gustafsson - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - USA - - EMail: gson@nominum.com - - - - - - - - - - - - - - - - - - - - - - - -Stapp, et al. Expires January 14, 2005 [Page 9] - -Internet-Draft The DHCID RR July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Stapp, et al. Expires January 14, 2005 [Page 10] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt deleted file mode 100644 index bcc2b4ec516e0..0000000000000 --- 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-intro-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt deleted file mode 100644 index 0783e7b26e146..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-intro-11.txt +++ /dev/null @@ -1,1457 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: January 13, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - July 15, 2004 - - - DNS Security Introduction and Requirements - draft-ietf-dnsext-dnssec-intro-11 - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - The Domain Name System Security Extensions (DNSSEC) add data origin - authentication and data integrity to the Domain Name System. This - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - document introduces these extensions, and describes their - capabilities and limitations. This document also discusses the - services that the DNS security extensions do and do not provide. - Last, this document describes the interrelationships between the - group of documents that collectively describe DNSSEC. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 - 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 - 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 - 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 - 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 - 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 - 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 - 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 - 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 - 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 - 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 - 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 - 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . 26 - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -1. Introduction - - This document introduces the Domain Name System Security Extensions - (DNSSEC). This document and its two companion documents - ([I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the - security extensions defined in RFC 2535 [RFC2535] and its - predecessors. These security extensions consist of a set of new - resource record types and modifications to the existing DNS protocol - [RFC1035]. The new records and protocol modifications are not fully - described in this document, but are described in a family of - documents outlined in Section 10. Section 3 and Section 4 describe - the capabilities and limitations of the security extensions in - greater detail. Section 5 discusses the scope of the document set. - Section 6, Section 7, Section 8, and Section 9 discuss the effect - that these security extensions will have on resolvers, stub - resolvers, zones and name servers. - - This document and its two companions update and obsolete RFCs 2535 - [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 - [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress - [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but - does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 - [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts - of 3226 [RFC3226] (dealing with DNSSEC). - - The DNS security extensions provide origin authentication and - integrity protection for DNS data, as well as a means of public key - distribution. These extensions do not provide confidentiality. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 3] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -2. Definitions of Important DNSSEC Terms - - This section defines a number of terms used in this document set. - Since this is intended to be useful as a reference while reading the - rest of the document set, first-time readers may wish to skim this - section quickly, read the rest of this document, then come back to - this section. - - Authentication Chain: An alternating sequence of DNSKEY RRsets and DS - RRsets forms a chain of signed data, with each link in the chain - vouching for the next. A DNSKEY RR is used to verify the - signature covering a DS RR and allows the DS RR to be - authenticated. The DS RR contains a hash of another DNSKEY RR and - this new DNSKEY RR is authenticated by matching the hash in the DS - RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset - and, in turn, some DNSKEY RR in this set may be used to - authenticate another DS RR and so forth until the chain finally - ends with a DNSKEY RR whose corresponding private key signs the - desired DNS data. For example, the root DNSKEY RRset can be used - to authenticate the DS RRset for "example." The "example." DS - RRset contains a hash that matches some "example." DNSKEY, and - this DNSKEY's corresponding private key signs the "example." - DNSKEY RRset. Private key counterparts of the "example." DNSKEY - RRset sign data records such as "www.example." as well as DS RRs - for delegations such as "subzone.example." - - Authentication Key: A public key that a security-aware resolver has - verified and can therefore use to authenticate data. A - security-aware resolver can obtain authentication keys in three - ways. First, the resolver is generally configured to know about - at least one public key; this configured data is usually either - the public key itself or a hash of the public key as found in the - DS RR (see "trust anchor"). Second, the resolver may use an - authenticated public key to verify a DS RR and the DNSKEY RR to - which the DS RR refers. Third, the resolver may be able to - determine that a new public key has been signed by the private key - corresponding to another public key which the resolver has - verified. Note that the resolver must always be guided by local - policy when deciding whether to authenticate a new public key, - even if the local policy is simply to authenticate any new public - key for which the resolver is able verify the signature. - - Delegation Point: Term used to describe the name at the parental side - of a zone cut. That is, the delegation point for "foo.example" - would be the foo.example node in the "example" zone (as opposed to - the zone apex of the "foo.example" zone). - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - Island of Security: Term used to describe a signed, delegated zone - that does not have an authentication chain from its delegating - parent. That is, there is no DS RR containing a hash of a DNSKEY - RR for the island in its delegating parent zone (see - [I-D.ietf-dnsext-dnssec-records]). An island of security is - served by security-aware name servers and may provide - authentication chains to any delegated child zones. Responses - from an island of security or its descendents can only be - authenticated if its authentication keys can be authenticated by - some trusted means out of band from the DNS protocol. - - Key Signing Key (KSK): An authentication key that corresponds to a - private key used to sign one or more other authentication keys for - a given zone. Typically, the private key corresponding to a key - signing key will sign a zone signing key, which in turn has a - corresponding private key which will sign other zone data. Local - policy may require the zone signing key to be changed frequently, - while the key signing key may have a longer validity period in - order to provide a more stable secure entry point into the zone. - Designating an authentication key as a key signing key is purely - an operational issue: DNSSEC validation does not distinguish - between key signing keys and other DNSSEC authentication keys, and - it is possible to use a single key as both a key signing key and a - zone signing key. Key signing keys are discussed in more detail - in [RFC3757]. Also see: zone signing key. - - Non-Validating Security-Aware Stub Resolver: A security-aware stub - resolver which trusts one or more security-aware recursive name - servers to perform most of the tasks discussed in this document - set on its behalf. In particular, a non-validating security-aware - stub resolver is an entity which sends DNS queries, receives DNS - responses, and is capable of establishing an appropriately secured - channel to a security-aware recursive name server which will - provide these services on behalf of the security-aware stub - resolver. See also: security-aware stub resolver, validating - security-aware stub resolver. - - Non-Validating Stub Resolver: A less tedious term for a - non-validating security-aware stub resolver. - - Security-Aware Name Server: An entity acting in the role of a name - server (defined in section 2.4 of [RFC1034]) that understands the - DNS security extensions defined in this document set. In - particular, a security-aware name server is an entity which - receives DNS queries, sends DNS responses, supports the EDNS0 - [RFC2671] message size extension and the DO bit [RFC3225], and - supports the RR types and message header bits defined in this - document set. - - - -Arends, et al. Expires January 13, 2005 [Page 5] - - - Security-Aware Recursive Name Server: An entity which acts in both - the security-aware name server and security-aware resolver roles. - A more cumbersome equivalent phrase would be "a security-aware - name server which offers recursive service". - - Security-Aware Resolver: An entity acting in the role of a resolver - (defined in section 2.4 of [RFC1034]) which understands the DNS - security extensions defined in this document set. In particular, - a security-aware resolver is an entity which sends DNS queries, - receives DNS responses, supports the EDNS0 [RFC2671] message size - extension and the DO bit [RFC3225], and is capable of using the RR - types and message header bits defined in this document set to - provide DNSSEC services. - - Security-Aware Stub Resolver: An entity acting in the role of a stub - resolver (defined in section 5.3.1 of [RFC1034]) which has enough - of an understanding the DNS security extensions defined in this - document set to provide additional services not available from a - security-oblivious stub resolver. Security-aware stub resolvers - may be either "validating" or "non-validating" depending on - whether the stub resolver attempts to verify DNSSEC signatures on - its own or trusts a friendly security-aware name server to do so. - See also: validating stub resolver, non-validating stub resolver. - - Security-Oblivious <anything>: An <anything> that is not - "security-aware". - - Signed Zone: A zone whose RRsets are signed and which contains - properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS - records. - - Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A - validating security-aware resolver uses this public key or hash as - a starting point for building the authentication chain to a signed - DNS response. In general, a validating resolver will need to - obtain the initial values of its trust anchors via some secure or - trusted means outside the DNS protocol. Presence of a trust - anchor also implies that the resolver should expect the zone to - which the trust anchor points to be signed. - - Unsigned Zone: A zone that is not signed. - - Validating Security-Aware Stub Resolver: A security-aware resolver - that sends queries in recursive mode but which performs signature - validation on its own rather than just blindly trusting an - upstream security-aware recursive name server. See also: - security-aware stub resolver, non-validating security-aware stub - resolver. - - - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - Validating Stub Resolver: A less tedious term for a validating - security-aware stub resolver. - - Zone Signing Key (ZSK): An authentication key that corresponds to a - private key used to sign a zone. Typically a zone signing key - will be part of the same DNSKEY RRset as the key signing key whose - corresponding private key signs this DNSKEY RRset, but the zone - signing key is used for a slightly different purpose, and may - differ from the key signing key in other ways, such as validity - lifetime. Designating an authentication key as a zone signing key - is purely an operational issue: DNSSEC validation does not - distinguish between zone signing keys and other DNSSEC - authentication keys, and it is possible to use a single key as - both a key signing key and a zone signing key. See also: key - signing key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -3. Services Provided by DNS Security - - The Domain Name System (DNS) security extensions provide origin - authentication and integrity assurance services for DNS data, - including mechanisms for authenticated denial of existence of DNS - data. These mechanisms are described below. - - These mechanisms require changes to the DNS protocol. DNSSEC adds - four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two - new message header bits (CD and AD). In order to support the larger - DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also - requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support - for the DO bit [RFC3225], so that a security-aware resolver can - indicate in its queries that it wishes to receive DNSSEC RRs in - response messages. - - These services protect against most of the threats to the Domain Name - System described in [I-D.ietf-dnsext-dns-threats]. - -3.1 Data Origin Authentication and Data Integrity - - DNSSEC provides authentication by associating cryptographically - generated digital signatures with DNS RRsets. These digital - signatures are stored in a new resource record, the RRSIG record. - Typically, there will be a single private key that signs a zone's - data, but multiple keys are possible: for example, there may be keys - for each of several different digital signature algorithms. If a - security-aware resolver reliably learns a zone's public key, it can - authenticate that zone's signed data. An important DNSSEC concept is - that the key that signs a zone's data is associated with the zone - itself and not with the zone's authoritative name servers (public - keys for DNS transaction authentication mechanisms may also appear in - zones, as described in [RFC2931], but DNSSEC itself is concerned with - object security of DNS data, not channel security of DNS - transactions. The keys associated with transaction security may be - stored in different RR types. See [RFC3755] for details.). - - A security-aware resolver can learn a zone's public key either by - having a trust anchor configured into the resolver or by normal DNS - resolution. To allow the latter, public keys are stored in a new - type of resource record, the DNSKEY RR. Note that the private keys - used to sign zone data must be kept secure, and should be stored - offline when practical to do so. To discover a public key reliably - via DNS resolution, the target key itself needs to be signed by - either a configured authentication key or another key that has been - authenticated previously. Security-aware resolvers authenticate zone - information by forming an authentication chain from a newly learned - public key back to a previously known authentication public key, - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - which in turn either has been configured into the resolver or must - have been learned and verified previously. Therefore, the resolver - must be configured with at least one trust anchor. If the configured - key is a zone signing key, then it will authenticate the associated - zone; if the configured key is a key signing key, it will - authenticate a zone signing key. If the resolver has been configured - with the hash of a key rather than the key itself, the resolver may - need to obtain the key via a DNS query. To help security-aware - resolvers establish this authentication chain, security-aware name - servers attempt to send the signature(s) needed to authenticate a - zone's public key(s) in the DNS reply message along with the public - key itself, provided there is space available in the message. - - The Delegation Signer (DS) RR type simplifies some of the - administrative tasks involved in signing delegations across - organizational boundaries. The DS RRset resides at a delegation - point in a parent zone and indicates the public key(s) corresponding - to the private key(s) used to self-sign the DNSKEY RRset at the - delegated child zone's apex. The administrator of the child zone, in - turn, uses the private key(s) corresponding to one or more of the - public keys in this DNSKEY RRset to sign the child zone's data. The - typical authentication chain is therefore - DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more - DS->DNSKEY subchains. DNSSEC permits more complex authentication - chains, such as additional layers of DNSKEY RRs signing other DNSKEY - RRs within a zone. - - A security-aware resolver normally constructs this authentication - chain from the root of the DNS hierarchy down to the leaf zones based - on configured knowledge of the public key for the root. Local - policy, however, may also allow a security-aware resolver to use one - or more configured public keys (or hashes of public keys) other than - the root public key, or may not provide configured knowledge of the - root public key, or may prevent the resolver from using particular - public keys for arbitrary reasons even if those public keys are - properly signed with verifiable signatures. DNSSEC provides - mechanisms by which a security-aware resolver can determine whether - an RRset's signature is "valid" within the meaning of DNSSEC. In the - final analysis however, authenticating both DNS keys and data is a - matter of local policy, which may extend or even override the - protocol extensions defined in this document set. See Section 5 for - further discussion. - -3.2 Authenticating Name and Type Non-Existence - - The security mechanism described in Section 3.1 only provides a way - to sign existing RRsets in a zone. The problem of providing negative - responses with the same level of authentication and integrity - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - requires the use of another new resource record type, the NSEC - record. The NSEC record allows a security-aware resolver to - authenticate a negative reply for either name or type non-existence - via the same mechanisms used to authenticate other DNS replies. Use - of NSEC records requires a canonical representation and ordering for - domain names in zones. Chains of NSEC records explicitly describe - the gaps, or "empty space", between domain names in a zone, as well - as listing the types of RRsets present at existing names. Each NSEC - record is signed and authenticated using the mechanisms described in - Section 3.1. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -4. Services Not Provided by DNS Security - - DNS was originally designed with the assumptions that the DNS will - return the same answer to any given query regardless of who may have - issued the query, and that all data in the DNS is thus visible. - Accordingly, DNSSEC is not designed to provide confidentiality, - access control lists, or other means of differentiating between - inquirers. - - DNSSEC provides no protection against denial of service attacks. - Security-aware resolvers and security-aware name servers are - vulnerable to an additional class of denial of service attacks based - on cryptographic operations. Please see Section 12 for details. - - The DNS security extensions provide data and origin authentication - for DNS data. The mechanisms outlined above are not designed to - protect operations such as zone transfers and dynamic update - [RFC3007]. Message authentication schemes described in [RFC2845] and - [RFC2931] address security operations that pertain to these - transactions. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -5. Scope of the DNSSEC Document Set and Last Hop Issues - - The specification in this document set defines the behavior for zone - signers and security-aware name servers and resolvers in such a way - that the validating entities can unambiguously determine the state of - the data. - - A validating resolver can determine these 4 states: - - Secure: The validating resolver has a trust anchor, a chain of trust - and is able to verify all the signatures in the response. - - Insecure: The validating resolver has a trust anchor, a chain of - trust, and, at some delegation point, signed proof of the - non-existence of a DS record. That indicates that subsequent - branches in the tree are provably insecure. A validating resolver - may have local policy to mark parts of the domain space as - insecure. - - Bogus: The validating resolver has a trust anchor and there is a - secure delegation which is indicating that subsidiary data will be - signed, but the response fails to validate due to one or more - reasons: missing signatures, expired signatures, signatures with - unsupported algorithms, data missing which the relevant NSEC RR - says should be present, and so forth. - - Indeterminate: There is no trust anchor which would indicate that a - specific portion of the tree is secure. This is the default - operation mode. - - This specification only defines how security aware name servers can - signal non-validating stub resolvers that data was found to be bogus - (using RCODE=2, "Server Failure" -- see - [I-D.ietf-dnsext-dnssec-protocol]). - - There is a mechanism for security aware name servers to signal - security-aware stub resolvers that data was found to be secure (using - the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). - - This specification does not define a format for communicating why - responses were found to be bogus or marked as insecure. The current - signaling mechanism does not distinguish between indeterminate and - insecure. - - A method for signaling advanced error codes and policy between a - security aware stub resolver and security aware recursive nameservers - is a topic for future work, as is the interface between a security - aware resolver and the applications that use it. Note, however, that - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - the lack of the specification of such communication does not prohibit - deployment of signed zones or the deployment of security aware - recursive name servers that prohibit propagation of bogus data to the - applications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -6. Resolver Considerations - - A security-aware resolver needs to be able to perform cryptographic - functions necessary to verify digital signatures using at least the - mandatory-to-implement algorithm(s). Security-aware resolvers must - also be capable of forming an authentication chain from a newly - learned zone back to an authentication key, as described above. This - process might require additional queries to intermediate DNS zones to - obtain necessary DNSKEY, DS and RRSIG records. A security-aware - resolver should be configured with at least one trust anchor as the - starting point from which it will attempt to establish authentication - chains. - - If a security-aware resolver is separated from the relevant - authoritative name servers by a recursive name server or by any sort - of device which acts as a proxy for DNS, and if the recursive name - server or proxy is not security-aware, the security-aware resolver - may not be capable of operating in a secure mode. For example, if a - security-aware resolver's packets are routed through a network - address translation device that includes a DNS proxy which is not - security-aware, the security-aware resolver may find it difficult or - impossible to obtain or validate signed DNS data. - - If a security-aware resolver must rely on an unsigned zone or a name - server that is not security aware, the resolver may not be able to - validate DNS responses, and will need a local policy on whether to - accept unverified responses. - - A security-aware resolver should take a signature's validation period - into consideration when determining the TTL of data in its cache, to - avoid caching signed data beyond the validity period of the - signature, but should also allow for the possibility that the - security-aware resolver's own clock is wrong. Thus, a security-aware - resolver which is part of a security-aware recursive name server will - need to pay careful attention to the DNSSEC "checking disabled" (CD) - bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid - blocking valid signatures from getting through to other - security-aware resolvers which are clients of this recursive name - server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure - recursive server handles queries with the CD bit set. - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -7. Stub Resolver Considerations - - Although not strictly required to do so by the protocol, most DNS - queries originate from stub resolvers. Stub resolvers, by - definition, are minimal DNS resolvers which use recursive query mode - to offload most of the work of DNS resolution to a recursive name - server. Given the widespread use of stub resolvers, the DNSSEC - architecture has to take stub resolvers into account, but the - security features needed in a stub resolver differ in some respects - from those needed in a full security-aware resolver. - - Even a security-oblivious stub resolver may get some benefit from - DNSSEC if the recursive name servers it uses are security-aware, but - for the stub resolver to place any real reliance on DNSSEC services, - the stub resolver must trust both the recursive name servers in - question and the communication channels between itself and those name - servers. The first of these issues is a local policy issue: in - essence, a security-oblivious stub resolver has no real choice but to - place itself at the mercy of the recursive name servers that it uses, - since it does not perform DNSSEC validity checks on its own. The - second issue requires some kind of channel security mechanism; proper - use of DNS transaction authentication mechanisms such as SIG(0) or - TSIG would suffice, as would appropriate use of IPsec, and particular - implementations may have other choices available, such as operating - system specific interprocess communication mechanisms. - Confidentiality is not needed for this channel, but data integrity - and message authentication are. - - A security-aware stub resolver that does trust both its recursive - name servers and its communication channel to them may choose to - examine the setting of the AD bit in the message header of the - response messages it receives. The stub resolver can use this flag - bit as a hint to find out whether the recursive name server was able - to validate signatures for all of the data in the Answer and - Authority sections of the response. - - There is one more step that a security-aware stub resolver can take - if, for whatever reason, it is not able to establish a useful trust - relationship with the recursive name servers which it uses: it can - perform its own signature validation, by setting the Checking - Disabled (CD) bit in its query messages. A validating stub resolver - is thus able to treat the DNSSEC signatures as a trust relationship - between the zone administrator and the stub resolver itself. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -8. Zone Considerations - - There are several differences between signed and unsigned zones. A - signed zone will contain additional security-related records (RRSIG, - DNSKEY, DS and NSEC records). RRSIG and NSEC records may be - generated by a signing process prior to serving the zone. The RRSIG - records that accompany zone data have defined inception and - expiration times, which establish a validity period for the - signatures and the zone data the signatures cover. - -8.1 TTL values vs. RRSIG validity period - - It is important to note the distinction between a RRset's TTL value - and the signature validity period specified by the RRSIG RR covering - that RRset. DNSSEC does not change the definition or function of the - TTL value, which is intended to maintain database coherency in - caches. A caching resolver purges RRsets from its cache no later - than the end of the time period specified by the TTL fields of those - RRsets, regardless of whether or not the resolver is security-aware. - - The inception and expiration fields in the RRSIG RR - [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time - period during which the signature can be used to validate the covered - RRset. The signatures associated with signed zone data are only - valid for the time period specified by these fields in the RRSIG RRs - in question. TTL values cannot extend the validity period of signed - RRsets in a resolver's cache, but the resolver may use the time - remaining before expiration of the signature validity period of a - signed RRset as an upper bound for the TTL of the signed RRset and - its associated RRSIG RR in the resolver's cache. - -8.2 New Temporal Dependency Issues for Zones - - Information in a signed zone has a temporal dependency which did not - exist in the original DNS protocol. A signed zone requires regular - maintenance to ensure that each RRset in the zone has a current valid - RRSIG RR. The signature validity period of an RRSIG RR is an - interval during which the signature for one particular signed RRset - can be considered valid, and the signatures of different RRsets in a - zone may expire at different times. Re-signing one or more RRsets in - a zone will change one or more RRSIG RRs, which in turn will require - incrementing the zone's SOA serial number to indicate that a zone - change has occurred and re-signing the SOA RRset itself. Thus, - re-signing any RRset in a zone may also trigger DNS NOTIFY messages - and zone transfers operations. - - - - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -9. Name Server Considerations - - A security-aware name server should include the appropriate DNSSEC - records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from - resolvers which have signaled their willingness to receive such - records via use of the DO bit in the EDNS header, subject to message - size limitations. Since inclusion of these DNSSEC RRs could easily - cause UDP message truncation and fallback to TCP, a security-aware - name server must also support the EDNS "sender's UDP payload" - mechanism. - - If possible, the private half of each DNSSEC key pair should be kept - offline, but this will not be possible for a zone for which DNS - dynamic update has been enabled. In the dynamic update case, the - primary master server for the zone will have to re-sign the zone when - updated, so the private key corresponding to the zone signing key - will have to be kept online. This is an example of a situation where - the ability to separate the zone's DNSKEY RRset into zone signing - key(s) and key signing key(s) may be useful, since the key signing - key(s) in such a case can still be kept offline and may have a longer - useful lifetime than the zone signing key(s). - - DNSSEC, by itself, is not enough to protect the integrity of an - entire zone during zone transfer operations, since even a signed zone - contains some unsigned, nonauthoritative data if the zone has any - children. Therefore, zone maintenance operations will require some - additional mechanisms (most likely some form of channel security, - such as TSIG, SIG(0), or IPsec). - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -10. DNS Security Document Family - - The DNSSEC document set can be partitioned into several main groups, - under the larger umbrella of the DNS base protocol documents. - - The "DNSSEC protocol document set" refers to the three documents - which form the core of the DNS security extensions: - 1. DNS Security Introduction and Requirements (this document) - 2. Resource Records for DNS Security Extensions - [I-D.ietf-dnsext-dnssec-records] - 3. Protocol Modifications for the DNS Security Extensions - [I-D.ietf-dnsext-dnssec-protocol] - - Additionally, any document that would add to, or change the core DNS - Security extensions would fall into this category. This includes any - future work on the communication between security-aware stub - resolvers and upstream security-aware recursive name servers. - - The "Digital Signature Algorithm Specification" document set refers - to the group of documents that describe how specific digital - signature algorithms should be implemented to fit the DNSSEC resource - record format. Each document in this set deals with a specific - digital signature algorithm. - - The "Transaction Authentication Protocol" document set refers to the - group of documents that deal with DNS message authentication, - including secret key establishment and verification. While not - strictly part of the DNSSEC specification as defined in this set of - documents, this group is noted because of its relationship to DNSSEC. - - The final document set, "New Security Uses", refers to documents that - seek to use proposed DNS Security extensions for other security - related purposes. DNSSEC does not provide any direct security for - these new uses, but may be used to support them. Documents that fall - in this category include the use of DNS in the storage and - distribution of certificates [RFC2538]. - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 18] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -11. IANA Considerations - - This overview document introduces no new IANA considerations. Please - see [I-D.ietf-dnsext-dnssec-records] for a complete review of the - IANA considerations introduced by DNSSEC. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -12. Security Considerations - - This document introduces the DNS security extensions and describes - the document set that contains the new security records and DNS - protocol modifications. The extensions provide data origin - authentication and data integrity using digital signatures over - resource record sets.This document discusses the capabilities and - limitations of these extensions. - - In order for a security-aware resolver to validate a DNS response, - all zones along the path from the trusted starting point to the zone - containing the response zones must be signed, and all name servers - and resolvers involved in the resolution process must be - security-aware, as defined in this document set. A security-aware - resolver cannot verify responses originating from an unsigned zone, - from a zone not served by a security-aware name server, or for any - DNS data which the resolver is only able to obtain through a - recursive name server which is not security-aware. If there is a - break in the authentication chain such that a security-aware resolver - cannot obtain and validate the authentication keys it needs, then the - security-aware resolver cannot validate the affected DNS data. - - This document briefly discusses other methods of adding security to a - DNS query, such as using a channel secured by IPsec or using a DNS - transaction authentication mechanism, but transaction security is not - part of DNSSEC per se. - - A non-validating security-aware stub resolver, by definition, does - not perform DNSSEC signature validation on its own, and thus is - vulnerable both to attacks on (and by) the security-aware recursive - name servers which perform these checks on its behalf and also to - attacks on its communication with those security-aware recursive name - servers. Non-validating security-aware stub resolvers should use - some form of channel security to defend against the latter threat. - The only known defense against the former threat would be for the - security-aware stub resolver to perform its own signature validation, - at which point, again by definition, it would no longer be a - non-validating security-aware stub resolver. - - DNSSEC does not protect against denial of service attacks. DNSSEC - makes DNS vulnerable to a new class of denial of service attacks - based on cryptographic operations against security-aware resolvers - and security-aware name servers, since an attacker can attempt to use - DNSSEC mechanisms to consume a victim's resources. This class of - attacks takes at least two forms. An attacker may be able to consume - resources in a security-aware resolver's signature validation code by - tampering with RRSIG RRs in response messages or by constructing - needlessly complex signature chains. An attacker may also be able to - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - consume resources in a security-aware name server which supports DNS - dynamic update, by sending a stream of update messages that force the - security-aware name server to re-sign some RRsets in the zone more - frequently than would otherwise be necessary. - - DNSSEC does not provide confidentiality, due to a deliberate design - choice. - - DNSSEC introduces the ability for a hostile party to enumerate all - the names in a zone by following the NSEC chain. NSEC RRs assert - which names do not exist in a zone by linking from existing name to - existing name along a canonical ordering of all the names within a - zone. Thus, an attacker can query these NSEC RRs in sequence to - obtain all the names in a zone. While not an attack on the DNS - itself, this could allow an attacker to map network hosts or other - resources by enumerating the contents of a zone. - - DNSSEC introduces significant additional complexity to the DNS, and - thus introduces many new opportunities for implementation bugs and - misconfigured zones. In particular, enabling DNSSEC signature - validation in a resolver may cause entire legitimate zones to become - effectively unreachable due to DNSSEC configuration errors or bugs. - - DNSSEC does not protect against tampering with unsigned zone data. - Non-authoritative data at zone cuts (glue and NS RRs in the parent - zone) are not signed. This does not pose a problem when validating - the authentication chain, but does mean that the non-authoritative - data itself is vulnerable to tampering during zone transfer - operations. Thus, while DNSSEC can provide data origin - authentication and data integrity for RRsets, it cannot do so for - zones, and other mechanisms must be used to protect zone transfer - operations. - - Please see [I-D.ietf-dnsext-dnssec-records] and - [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations. - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 21] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -13. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group. While explicitly listing everyone - who has contributed during the decade during which DNSSEC has been - under development would be an impossible task, the editors would - particularly like to thank the following people for their - contributions to and comments on this document set: Jaap Akkerhuis, - Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, - David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald - Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, - Gilles Guette, Andreas Gustafsson, Jun-ichiro itojun Hagino, Phillip - Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, - Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon - Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, - Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, - Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ - Mundy, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, - Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob - Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington, and - Suzanne Woolf. - - No doubt the above list is incomplete. We apologize to anyone we - left out. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 22] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -14. References - -14.1 Normative References - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in - progress), May 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-08 (work in progress), - May 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - -14.2 Informative References - - [I-D.ietf-dnsext-dns-threats] - Atkins, D. and R. Austein, "Threat Analysis Of The Domain - Name System", draft-ietf-dnsext-dns-threats-07 (work in - progress), April 2004. - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - 2004. - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in - the Domain Name System (DNS)", RFC 2538, March 1999. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) - Signing Authority", RFC 3008, November 2000. - - [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. - - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 24] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - -Arends, et al. Expires January 13, 2005 [Page 25] - -Internet-Draft DNSSEC Introduction and Requirements July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 13, 2005 [Page 26] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt deleted file mode 100644 index 5728b35c9ba53..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-protocol-07.txt +++ /dev/null @@ -1,3193 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: January 13, 2005 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - July 15, 2004 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-07 - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents which describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 5 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 5 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 7 - 2.6 DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . . 8 - 2.7 Example of a Secure Zone . . . . . . . . . . . . . . . . . 8 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 10 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 10 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 11 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 11 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 14 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 15 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . 16 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 17 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 17 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 18 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 18 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 19 - 4.2 Signature Verification Support . . . . . . . . . . . . . . 19 - 4.3 Determining Security Status of Data . . . . . . . . . . . 20 - 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 20 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 21 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 - 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 - 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 - 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 - 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 23 - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 23 - 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 - 5.1 Special Considerations for Islands of Security . . . . . . 26 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 - 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 - 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 - 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . . 57 - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document - defines the concept of a signed zone and lists the requirements for - zone signing. Section 3 describes the modifications to authoritative - name server behavior necessary to handle signed zones. Section 4 - describes the behavior of entities which include security-aware - resolver functions. Finally, Section 5 defines how to use DNSSEC RRs - to authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034] and [RFC1035]. - - This document is part of a family of documents that define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]; the reader is assumed to be - familiar with this document. A definition of the DNSSEC resource - records can be found in [I-D.ietf-dnsext-dnssec-records]. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as a CNAME RR. - - DNSSEC specifies the placement of two new RR types, NSEC and DS, - which can be placed at the parental side of a zone cut (that is, at a - delegation point). This is an exception to the general prohibition - against putting data in the parent zone at a zone cut. Section 2.6 - describes this change. - -2.1 Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR - containing the corresponding public key. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set -- see Section - 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys associated - with other DNS operations MAY be stored in DNSKEY RRs that are not - marked as zone keys but MUST NOT be used to verify RRSIGs. - - If the zone administrator intends a signed zone to be usable other - than as an island of security, the zone apex MUST contain at least - one DNSKEY RR to act as a secure entry point into the zone. This - secure entry point could then be used as the target of a secure - delegation via a corresponding DS RR in the parent zone (see - [I-D.ietf-dnsext-dnssec-records]). - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets all of the following requirements: - o The RRSIG owner name is equal to the RRset owner name; - o The RRSIG class is equal to the RRset class; - o The RRSIG Type Covered field is equal to the RRset type; - o The RRSIG Original TTL field is equal to the TTL of the RRset; - o The RRSIG RR's TTL is equal to the TTL of the RRset; - o The RRSIG Labels field is equal to the number of labels in the - RRset owner name, not counting the null root label and not - - - -Arends, et al. Expires January 13, 2005 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - counting the leftmost label if it is a wildcard; - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - The process for constructing the RRSIG RR for a given RRset is - described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated - with delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset - located at the delegating parent (if any). - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone which has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - format of NSEC RRs and the process for constructing the NSEC RR for a - given name is described in [I-D.ietf-dnsext-dnssec-records]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner names nodes which were - not the owner name of any RRset before the zone was signed. The main - reasons for this are a desire for namespace consistency between - signed and unsigned versions of the same zone and a desire to reduce - the risk of response inconsistency in security oblivious recursive - name servers. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - The difference between the set of owner names that require RRSIG - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part is - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and any - RRsets for which the parent zone has authoritative data MUST be set; - bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be clear. - -2.4 Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (that is, the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5 Changes to the CNAME Resource Record. - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - -2.6 DNSSEC RR Types Appearing at Zone Cuts. - - DNSSEC introduced two new RR types that are unusual in that they can - appear at the parental side of a zone cut. At the parental side of a - zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at - the owner name. A DS RR could also be present if the zone being - delegated is signed and wishes to have a chain of authentication to - the parent zone. This is an exception to the original DNS - specification ([RFC1034]) which states that only NS RRsets could - appear at the parental side of a zone cut. - - This specification updates the original DNS specification to allow - NSEC and DS RR types at the parent side of a zone cut. These RRsets - are authoritative for the parent when they appear at the parent side - of a zone cut. - -2.7 Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements. Functions specific to security-aware recursive name - servers are described in Section 3.2; functions specific to - authoritative servers are described in Section 3.1. - - The terms "SNAME", "SCLASS", and "STYPE" in the following discussion - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. - - A security-aware name server which receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit clear MUST - treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset, - and MUST NOT perform any of the additional processing described - below. Since the DS RR type has the peculiar property of only - existing in the parent zone at delegation points, DS RRs always - require some special processing, as described in Section 3.1.4.1. - - Security aware name servers that receive explicit queries for - security RR types which match the content of more than one zone that - it serves (for example, NSEC and RRSIG RRs above and below a - delegation point where the server is authoritative for both zones) - should behave self-consistently. The name server MAY return one of - the following: - o The above-delegation RRsets - o The below-delegation RRsets - o Both above and below-delegation RRsets - o Empty answer section (no records) - o Some other response - o An error - As long as the response is always consistent for each query to the - name server. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Section 3.1.6, - Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details - on the behavior of these bits. - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - A security aware name server which synthesizes CNAME RRs from DNAME - RRs as described in [RFC2672] SHOULD NOT generate signatures for the - synthesized CNAME RRs. - -3.1 Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set, a security-aware authoritative name - server for a signed zone MUST include additional RRSIG, NSEC, and DS - RRs according to the following rules: - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1; - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3; - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - These rules only apply to responses the semantics of which convey - information about the presence or absence of resource records. That - is, these rules are not intended to rule out responses such as RCODE - 4 ("Not Implemented") or RCODE 5 ("Refused"). - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1 Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server SHOULD attempt to send RRSIG RRs that a - security-aware resolver can use to authenticate the RRsets in the - response. A name server SHOULD make every attempt to keep the RRset - and its associated RRSIG(s) together in a response. Inclusion of - RRSIG RRs in a response is subject to the following rules: - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may need to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may need to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If - this happens, the name server MUST NOT set the TC bit solely - because these RRSIG RRs didn't fit. - -3.1.2 Including DNSKEY RRs In a Response - - When responding to a query that has the DO bit set and that requests - the SOA or NS RRs at the apex of a signed zone, a security-aware - authoritative name server for that zone MAY return the zone apex - DNSKEY RRset in the Additional section. In this situation, the - DNSKEY RRset and associated RRSIG RRs have lower priority than any - other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - -3.1.3 Including NSEC RRs In a Response - - When responding to a query that has the DO bit set, a security-aware - authoritative name server for a signed zone MUST include NSEC RRs in - each of the following cases: - - No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>, - but does not contain any RRsets that exactly match <SNAME, SCLASS, - STYPE>. - - Name Error: The zone does not contain any RRsets that match <SNAME, - SCLASS> either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS> but does contain an RRset that matches - <SNAME, SCLASS, STYPE> via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match <SNAME, SCLASS>, does contain one or more RRsets that match - <SNAME, SCLASS> via wildcard name expansion, but does not contain - any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name - expansion. - - In each of these cases, the name server includes NSEC RRs in the - response to prove that an exact match for <SNAME, SCLASS, STYPE> was - not present in the zone and that the response that the name server is - returning is correct given the data that are in the zone. - - - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -3.1.3.1 Including NSEC RRs: No Data Response - - If the zone contains RRsets matching <SNAME, SCLASS> but contains no - RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST - include the NSEC RR for <SNAME, SCLASS> along with its associated - RRSIG RR(s) in the Authority section of the response (see Section - 3.1.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RR(s), the name server MUST set the TC bit (see - Section 3.1.1). - - Since the search name exists, wildcard name expansion does not apply - to this query, and a single signed NSEC RR suffices to prove the - requested RR type does not exist. - -3.1.3.2 Including NSEC RRs: Name Error Response - - If the zone does not contain any RRsets matching <SNAME, SCLASS> - either exactly or via wildcard name expansion, then the name server - MUST include the following NSEC RRs in the Authority section, along - with their associated RRSIG RRs: - o An NSEC RR proving that there is no exact match for <SNAME, - SCLASS>; and - o An NSEC RR proving that the zone contains no RRsets that would - match <SNAME, SCLASS> via wildcard name expansion. - - In some cases a single NSEC RR may prove both of these points, in - that case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - Note that this form of response includes cases in which SNAME - corresponds to an empty non-terminal name within the zone (a name - which is not the owner name for any RRset but which is the parent - name of one or more RRsets). - -3.1.3.3 Including NSEC RRs: Wildcard Answer Response - - If the zone does not contain any RRsets which exactly match <SNAME, - SCLASS> but does contain an RRset which matches <SNAME, SCLASS, - STYPE> via wildcard name expansion, the name server MUST include the - wildcard-expanded answer and the corresponding wildcard-expanded - RRSIG RRs in the Answer section, and MUST include in the Authority - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - section an NSEC RR and associated RRSIG RR(s) proving that the zone - does not contain a closer match for <SNAME, SCLASS>. If space does - not permit inclusion of the answer, NSEC and RRSIG RRs, the name - server MUST set the TC bit (see Section 3.1.1). - -3.1.3.4 Including NSEC RRs: Wildcard No Data Response - - This case is a combination of the previous cases. The zone does not - contain an exact match for <SNAME, SCLASS>, and while the zone does - contain RRsets which match <SNAME, SCLASS> via wildcard expansion, - none of those RRsets match STYPE. The name server MUST include the - following NSEC RRs in the Authority section, along with their - associated RRSIG RRs: - o An NSEC RR proving that there are no RRsets matching STYPE at the - wildcard owner name which matched <SNAME, SCLASS> via wildcard - expansion; and - o An NSEC RR proving that there are no RRsets in the zone which - would have been a closer match for <SNAME, SCLASS>. - - In some cases a single NSEC RR may prove both of these points, in - which case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - -3.1.3.5 Finding The Right NSEC RRs - - As explained above, there are several situations in which a - security-aware authoritative name server needs to locate an NSEC RR - which proves that no RRsets matching a particular SNAME exist. - Locating such an NSEC RR within an authoritative zone is relatively - simple, at least in concept. The following discussion assumes that - the name server is authoritative for the zone which would have held - the nonexistent RRsets matching SNAME. The algorithm below is - written for clarity, not efficiency. - - To find the NSEC which proves that no RRsets matching name N exist in - the zone Z which would have held them, construct sequence S - consisting of the owner names of every RRset in Z, sorted into - canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate - names. Find the name M which would have immediately preceded N in S - if any RRsets with owner name N had existed. M is the owner name of - the NSEC RR which proves that no RRsets exist with owner name N. - - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - The algorithm for finding the NSEC RR which proves that a given name - is not covered by any applicable wildcard is similar, but requires an - extra step. More precisely, the algorithm for finding the NSEC - proving that no RRsets exist with the applicable wildcard name is - precisely the same as the algorithm for finding the NSEC RR which - proves that RRsets with any other owner name do not exist: the part - that's missing is how to determine the name of the nonexistent - applicable wildcard. In practice, this is easy, because the - authoritative name server has already checked for the presence of - precisely this wildcard name as part of step (1)(c) of the normal - lookup algorithm described in Section 4.3.2 of [RFC1034]. - -3.1.4 Including DS RRs In a Response - - When responding to a query which has the DO bit set, a security-aware - authoritative name server returning a referral includes DNSSEC data - along with the NS RRset. - - If a DS RRset is present at the delegation point, the name server - MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG - RR(s). - - If no DS RRset is present at the delegation point, the name server - MUST return both the NSEC RR which proves that the DS RRset is not - present and the NSEC RR's associated RRSIG RR(s) along with the NS - RRset. The name server MUST place the NS RRset before the NSEC RRset - and its associated RRSIG RR(s). - - Including these DS, NSEC, and RRSIG RRs increases the size of - referral messages, and may cause some or all glue RRs to be omitted. - If space does not permit inclusion of the DS or NSEC RRset and - associated RRSIG RRs, the name server MUST set the TC bit (see - Section 3.1.1). - -3.1.4.1 Responding to Queries for DS RRs - - The DS resource record type is unusual in that it appears only on the - parent zone's side of a zone cut. For example, the DS RRset for the - delegation of "foo.example" is stored in the "example" zone rather - than in the "foo.example" zone. This requires special processing - rules for both name servers and resolvers, since the name server for - the child zone is authoritative for the name at the zone cut by the - normal DNS rules but the child zone does not contain the DS RRset. - - A security-aware resolver sends queries to the parent zone when - looking for a needed DS RR at a delegation point (see Section 4.2). - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - However, special rules are necessary to avoid confusing - security-oblivious resolvers which might become involved in - processing such a query (for example, in a network configuration that - forces a security-aware resolver to channel its queries through a - security-oblivious recursive name server). The rest of this section - describes how a security-aware name server processes DS queries in - order to avoid this problem. - - The need for special processing by a security-aware name server only - arises when all the following conditions are met: - o the name server has received a query for the DS RRset at a zone - cut; and - o the name server is authoritative for the child zone; and - o the name server is not authoritative for the parent zone; and - o the name server does not offer recursion. - - In all other cases, the name server either has some way of obtaining - the DS RRset or could not have been expected to have the DS RRset - even by the pre-DNSSEC processing rules, so the name server can - return either the DS RRset or an error response according to the - normal processing rules. - - If all of the above conditions are met, however, the name server is - authoritative for SNAME but cannot supply the requested RRset. In - this case, the name server MUST return an authoritative "no data" - response showing that the DS RRset does not exist in the child zone's - apex. See Appendix B.8 for an example of such a response. - -3.1.5 Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation. - - An authoritative name server is not required to verify that a zone is - properly signed before sending or accepting a zone transfer. - However, an authoritative name server MAY choose to reject the entire - zone transfer if the zone fails meets any of the signing requirements - described in Section 2. The primary objective of a zone transfer is - to ensure that all authoritative name servers have identical copies - of the zone. An authoritative name server that chooses to perform - its own zone validation MUST NOT selectively reject some RRs and - accept others. - - DS RRsets appear only on the parental side of a zone cut and are - authoritative data in the parent zone. As with any other - authoritative RRset, the DS RRset MUST be included in zone transfers - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - of the zone in which the RRset is authoritative data: in the case of - the DS RRset, this is the parent zone. - - NSEC RRs appear in both the parent and child zones at a zone cut, and - are authoritative data in both the parent and child zones. The - parental and child NSEC RRs at a zone cut are never identical to each - other, since the NSEC RR in the child zone's apex will always - indicate the presence of the child zone's SOA RR while the parental - NSEC RR at the zone cut will never indicate the presence of an SOA - RR. As with any other authoritative RRs, NSEC RRs MUST be included - in zone transfers of the zone in which they are authoritative data: - the parental NSEC RR at a zone cut MUST be included zone transfers of - the parent zone, while the NSEC at the zone apex of the child zone - MUST be included in zone transfers of the child zone. - - RRSIG RRs appear in both the parent and child zones at a zone cut, - and are authoritative in whichever zone contains the authoritative - RRset for which the RRSIG RR provides the signature. That is, the - RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be - authoritative in the parent zone, while the RRSIG for any RRset in - the child zone's apex will be authoritative in the child zone. - Parental and child RRSIG RRs at a zone cut will never be identical to - each other, since the Signer's Name field of an RRSIG RR in the child - zone's apex will indicate a DNSKEY RR in the child zone's apex while - the same field of a parental RRSIG RR at the zone cut will indicate a - DNSKEY RR in the parent zone's apex. As with any other authoritative - RRs, RRSIG RRs MUST be included in zone transfers of the zone in - which they are authoritative data. - -3.1.6 The AD and CD Bits in an Authoritative Response - - The CD and AD bits are designed for use in communication between - security-aware resolvers and security-aware recursive name servers. - These bits are for the most part not relevant to query processing by - security-aware authoritative name servers. - - A security-aware name server does not perform signature validation - for authoritative data during query processing even when the CD bit - is clear. A security-aware name server SHOULD clear the CD bit when - composing an authoritative response. - - A security-aware name server MUST NOT set the AD bit in a response - unless the name server considers all RRsets in the Answer and - Authority sections of the response to be authentic. A security-aware - name server's local policy MAY consider data from an authoritative - zone to be authentic without further validation, but the name server - MUST NOT do so unless the name server obtained the authoritative zone - via secure means (such as a secure zone transfer mechanism), and MUST - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - NOT do so unless this behavior has been configured explicitly. - - A security-aware name server which supports recursion MUST follow the - rules for the CD and AD bits given in Section 3.2 when generating a - response that involves data obtained via recursion. - -3.2 Recursive Name Servers - - As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware - recursive name server is an entity which acts in both the - security-aware name server and security-aware resolver roles. This - section uses the terms "name server side" and "resolver side" to - refer to the code within a security-aware recursive name server which - implements the security-aware name server role and the code which - implements the security-aware resolver role, respectively. - - The resolver side follows the usual rules for caching and negative - caching which would apply to any security-aware resolver. - -3.2.1 The DO bit - - The resolver side of a security-aware recursive name server MUST set - the DO bit when sending requests, regardless of the state of the DO - bit in the initiating request received by the name server side. If - the DO bit in an initiating query is not set, the name server side - MUST strip any authenticating DNSSEC RRs from the response, but MUST - NOT strip any DNSSEC RR types that the initiating query explicitly - requested. - -3.2.2 The CD bit - - The CD bit exists in order to allow a security-aware resolver to - disable signature validation in a security-aware name server's - processing of a particular query. - - The name server side MUST copy the setting of the CD bit from a query - to the corresponding response. - - The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest - of an initiating query, so that the resolver side will know whether - or not it is required to verify the response data it returns to the - name server side. If the CD bit is set, it indicates that the - originating resolver is willing to perform whatever authentication - its local policy requires, thus the resolver side of the recursive - name server need not perform authentication on the RRsets in the - response. When the CD bit is set the recursive name server SHOULD, - if possible, return the requested data to the originating resolver - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - even if the recursive name server's local authentication policy would - reject the records in question. That is, by setting the CD bit, the - originating resolver has indicated that it takes responsibility for - performing its own authentication, and the recursive name server - should not interfere. - - If the resolver side implements a BAD cache (see Section 4.7) and the - name server side receives a query which matches an entry in the - resolver side's BAD cache, the name server side's response depends on - the sense of the CD bit in the original query. If the CD bit is set, - the name server side SHOULD return the data from the BAD cache; if - the CD bit is not set, the name server side MUST return RCODE 2 - (server failure). - - The intent of the above rule is to provide the raw data to clients - which are capable of performing their own signature verification - checks while protecting clients which depend on the resolver side of - a security-aware recursive name server to perform such checks. - Several of the possible reasons why signature validation might fail - involve conditions which may not apply equally to the recursive name - server and the client which invoked it: for example, the recursive - name server's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security which the recursive name - server does not share. In such cases, "protecting" a client which is - capable of performing its own signature validation from ever seeing - the "bad" data does not help the client. - -3.2.3 The AD bit - - The name server side of a security-aware recursive name server MUST - NOT set the AD bit in a response unless the name server considers all - RRsets in the Answer and Authority sections of the response to be - authentic. The name server side SHOULD set the AD bit if and only if - the resolver side considers all RRsets in the Answer section and any - relevant negative response RRs in the Authority section to be - authentic. The resolver side MUST follow the procedure described in - Section 5 to determine whether the RRs in question are authentic. - However, for backwards compatibility, a recursive name server MAY set - the AD bit when a response includes unsigned CNAME RRs if those CNAME - RRs demonstrably could have been synthesized from an authentic DNAME - RR which is also included in the response according to the synthesis - rules described in [RFC2672]. - -3.3 Example DNSSEC Responses - - See Appendix B for example response packets. - - - - - -Arends, et al. Expires January 13, 2005 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -4. Resolving - - This section describes the behavior of entities that include - security-aware resolver functions. In many cases such functions will - be part of a security-aware recursive name server, but a stand-alone - security-aware resolver has many of the same requirements. Functions - specific to security-aware recursive name servers are described in - Section 3.2. - -4.1 EDNS Support - - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set when sending queries. - - A security-aware resolver MUST support a message size of at least - 1220 octets, SHOULD support a message size of 4000 octets, and MUST - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver - MUST handle fragmented UDP packets correctly regardless of whether - any such fragmented packets were received via IPv4 or IPv6. Please - see [RFC3226] for discussion of these requirements. - -4.2 Signature Verification Support - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and SHOULD apply them to every - received response except when: - o The security-aware resolver is part of a security-aware recursive - name server, and the response is the result of recursion on behalf - of a query received with the CD bit set; - o The response is the result of a query generated directly via some - form of application interface which instructed the security-aware - resolver not to perform validation for this query; or - o Validation for this query has been disabled by local policy. - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - Security aware resolvers MAY query for missing security RRs in an - attempt to perform validation; implementations that choose to do so - must be aware that the answers received may not be sufficient to - validate the original response. - - When attempting to retrieve missing NSEC RRs which reside on the - parental side at a zone cut, a security-aware iterative-mode resolver - MUST query the name servers for the parent zone, not the child zone. - - When attempting to retrieve a missing DS, a security-aware - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - iterative-mode resolver MUST query the name servers for the parent - zone, not the child zone. As explained in Section 3.1.4.1, - security-aware name servers need to apply special processing rules to - handle the DS RR, and in some situations the resolver may also need - to apply special rules to locate the name servers for the parent zone - if the resolver does not already have the parent's NS RRset. To - locate the parent NS RRset, the resolver can start with the - delegation name, strip off the leftmost label, and query for an NS - RRset by that name; if no NS RRset is present at that name, the - resolver then strips of the leftmost remaining label and retries the - query for that name, repeating this process of walking up the tree - until it either finds the NS RRset or runs out of labels. - -4.3 Determining Security Status of Data - - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between four - cases: - - Secure: An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted security anchor to the - RRset. In this case, the RRset should be signed, and is subject - to signature validation as described above. - - Insecure: An RRset for which the resolver knows that it has no chain - of signed DNSKEY and DS RRs from any trusted starting point to the - RRset. This can occur when the target RRset lies in an unsigned - zone or in a descendent of an unsigned zone. In this case, the - RRset may or may not be signed, but the resolver will not be able - to verify the signature. - - Bogus: An RRset for which the resolver believes that it ought to be - able to establish a chain of trust but is unable to do so, either - due to signatures that for some reason fail to validate or due to - missing data which the relevant DNSSEC RRs indicate should be - present. This case may indicate an attack, but may also indicate - a configuration error or some form of data corruption. - - Indeterminate: An RRset for which the resolver is not able to - determine whether or not the RRset should be signed, because the - resolver is not able to obtain the necessary DNSSEC RRs. This can - occur when the security-aware resolver is not able to contact - security-aware name servers for the relevant zones. - -4.4 Configured Trust Anchors - - A security-aware resolver MUST be capable of being configured with at - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - least one trusted public key or DS RR, and SHOULD be capable of being - configured with multiple trusted public keys or DS RRs. Since a - security-aware resolver will not be able to validate signatures - without such a configured trust anchor, the resolver SHOULD have some - reasonably robust mechanism for obtaining such keys when it boots; - examples of such a mechanism would be some form of non-volatile - storage (such as a disk drive) or some form of trusted local network - configuration mechanism. - - Note that trust anchors also covers key material that is updated in a - secure manner. This secure manner could be through physical media, a - key exchange protocol, or some other out of band means. - -4.5 Response Caching - - A security-aware resolver SHOULD cache each response as a single - atomic entry containing the entire answer, including the named RRset - and any associated DNSSEC RRs. The resolver SHOULD discard the - entire atomic entry when any of the RRs contained in it expire. In - most cases the appropriate cache index for the atomic entry will be - the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double <QNAME,QCLASS>. - - The reason for these recommendations is that, between the initial - query and the expiration of the data from the cache, the - authoritative data might have been changed (for example, via dynamic - update). - - There are two situations for which this is relevant: - 1. By using the RRSIG record, it is possible to deduce that an - answer was synthesized from a wildcard. A security aware - recursive name server could store this wildcard data and use it - to generate positive responses to queries other than the name for - which the original answer was first received. - 2. NSEC RRs received to prove the non-existence of a name could be - reused by a security aware resolver to prove the non-existence of - any name in the name range it spans. - - In theory, a resolver could use wildcards or NSEC RRs to generate - positive and negative responses (respectively) until the TTL or - signatures on the records in question expire. However, it seems - prudent for resolvers to avoid blocking new authoritative data or - synthesizing new data on their own. Resolvers which follow this - recommendation will have a more consistent view of the namespace. - - - - - - -Arends, et al. Expires January 13, 2005 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -4.6 Handling of the CD and AD bits - - A security-aware resolver MAY set a query's CD bit in order to - indicate that the resolver takes responsibility for performing - whatever authentication its local policy requires on the RRsets in - the response. See Section 3.2 for the effect this bit has on the - behavior of security-aware recursive name servers. - - A security-aware resolver MUST clear the AD bit when composing query - messages to protect against buggy name servers which blindly copy - header bits which they do not understand from the query message to - the response message. - - A resolver MUST disregard the meaning of the CD and AD bits in a - response unless the response was obtained using a secure channel or - the resolver was specifically configured to regard the message header - bits without using a secure channel. - -4.7 Caching BAD Data - - While many validation errors will be transient, some are likely to be - more persistent, such as those caused by administrative error - (failure to re-sign a zone, clock skew, and so forth). Since - requerying will not help in these cases, validating resolvers might - generate a significant amount of unnecessary DNS traffic as a result - of repeated queries for RRsets with persistent validation failures. - - To prevent such unnecessary DNS traffic, security-aware resolvers MAY - cache data with invalid signatures, with some restrictions. - Conceptually, caching such data is similar to negative caching - [RFC2308], except that instead of caching a valid negative response, - the resolver is caching the fact that a particular answer failed to - validate. This document refers to a cache of data with invalid - signatures as a "BAD cache". - - Resolvers which implement a BAD cache MUST take steps to prevent the - cache from being useful as a denial-of-service attack amplifier. In - particular: - o Since RRsets which fail to validate do not have trustworthy TTLs, - the implementation MUST assign a TTL. This TTL SHOULD be small, - in order to mitigate the effect of caching the results of an - attack. - o In order to prevent caching of a transient validation failure - (which might be the result of an attack), resolvers SHOULD track - queries that result in validation failures, and SHOULD only answer - from the BAD cache after the number of times that responses to - queries for that particular <QNAME, QTYPE, QCLASS> have failed to - validate exceeds a threshold value. - - - -Arends, et al. Expires January 13, 2005 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - Resolvers MUST NOT return RRsets from the BAD cache unless the - resolver is not required to validate the signatures of the RRsets in - question under the rules given in Section 4.2 of this document. See - Section 3.2.2 for discussion of how the responses returned by a - security-aware recursive name server interact with a BAD cache. - -4.8 Synthesized CNAMEs - - A validating security-aware resolver MUST treat the signature of a - valid signed DNAME RR as also covering unsigned CNAME RRs which could - have been synthesized from the DNAME RR as described in [RFC2672], at - least to the extent of not rejecting a response message solely - because it contains such CNAME RRs. The resolver MAY retain such - CNAME RRs in its cache or in the answers it hands back, but is not - required to do so. - -4.9 Stub resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - -4.9.1 Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application which - invoked it but is not required to do so. A non-validating stub - resolver that wishes to do this will need to set the DO bit in - receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, since - otherwise it will not receive the DNSSEC RRs it needs to perform - signature validation. - -4.9.2 Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless requested by the application layer, - since by definition, a non-validating stub resolver depends on the - security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - since otherwise the security-aware recursive name server will answer - the query using the name server's local policy, which may prevent the - stub resolver from receiving data which would be acceptable to the - stub resolver's local policy. - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -4.9.3 Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - which sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server, so as a practical matter there - may be little practical value to checking the status of the AD bit - except perhaps as a debugging aid. In any case, a security-aware - stub resolver MUST NOT place any reliance on signature validation - allegedly performed on its behalf except when the security-aware stub - resolver obtained the data in question from a trusted security-aware - recursive name server via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, since, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires configured knowledge of at least one authenticated - DNSKEY or DS RR. The process for obtaining and authenticating this - initial trust anchors is achieved via some external mechanism. For - example, a resolver could use some off-line authenticated exchange to - obtain a zone's DNSKEY RR or obtain a DS RR that identifies and - authenticates a zone's DNSKEY RR. The remainder of this section - assumes that the resolver has somehow obtained an initial set of - trust anchors. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag - (DNSKEY RDATA bit 7) set. - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset using an - initial DNSKEY RR, delegations from that zone can be authenticated - using DS RRs. This allows a resolver to start from an initial key, - and use DS RRsets to proceed recursively down the DNS tree obtaining - other apex DNSKEY RRsets. If the resolver were configured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as an upstream security-oblivious recursive name server - that accidentally interferes with DNSSEC RRs or due to a deliberate - attack in which an adversary forges a response, strips DNSSEC RRs - - - -Arends, et al. Expires January 13, 2005 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - from a response, or modifies a query so that DNSSEC RRs appear not to - be requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1 Special Considerations for Islands of Security - - Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed - zones for which it is not possible to construct an authentication - chain to the zone from its parent. Validating signatures within an - island of security requires the validator to have some other means of - obtaining an initial authenticated zone key for the island. If a - validator cannot obtain such a key, it SHOULD switch to operating as - if the zones in the island of security are unsigned. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a trust anchor for the authentication chain. - -5.2 Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3); - o The Algorithm and Key Tag in the DS RR match the Algorithm field - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset and, when hashed using the digest algorithm specified in the - DS RR's Digest Type field, results in a digest value that matches - the Digest field of the DS RR; and - - - -Arends, et al. Expires January 13, 2005 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - o The matching DNSKEY RR in the child zone has the Zone Flag bit - set, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the validator authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the validator can not authenticate RRsets in or below the - child zone. - - If the validator does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone, and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone, and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished, since the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3 Authenticating an RRset Using an RRSIG RR - - A validator can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The validator first checks the RRSIG - - - -Arends, et al. Expires January 13, 2005 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The validator then constructs the - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, the validator uses the public key and - signature to authenticate the signed data. Section 5.3.1, Section - 5.3.2, and Section 5.3.3 describe each step in detail. - -5.3.1 Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - o The RRSIG RR and the RRset MUST have the same owner name and the - same class; - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset; - o The RRSIG RR's Type Covered field MUST equal the RRset's type; - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field; - o The validator's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; - o The validator's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset; - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the validator cannot predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until either the signature is validated or the validator - has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - validator authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - o The apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a trust anchor. - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - - - -Arends, et al. Expires January 13, 2005 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - Section 5.3.1, the validator needs to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The validator should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | type | class | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - - - -Arends, et al. Expires January 13, 2005 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - RRset. - - The canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRset are present at the parent zone. The second NSEC RRset resides - at the child zone, and identifies which RRsets are present at the - apex in the child zone. The parent NSEC RRset and child NSEC RRset - can always be distinguished since only the child NSEC RRs will - specify an SOA RRset exists at the name. When reconstructing the - original NSEC RRset for the delegation from the parent zone, the NSEC - RRs MUST NOT be combined with NSEC RRs from the child zone, and when - reconstructing the original NSEC RRset for the apex of the child - zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent - zone. - - Note also that each of the two NSEC RRsets at a delegation point has - a corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -5.3.3 Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the validator can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types - and provides pointers to the documents that define each algorithm's - use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the validator can only - determine which DNSKEY RR by trying each matching public key until - the validator either succeeds in validating the signature or runs out - of keys to try. - - - -Arends, et al. Expires January 13, 2005 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also needs to test these RRSIG - RRs, and determines how to resolve conflicts if these RRSIG RRs lead - to differing results. - - If the resolver accepts the RRset as authentic, the validator MUST - set the TTL of the RRSIG RR and each RR in the authenticated RRset to - a value no greater than the minimum of: - o The RRset's TTL as received in the response; - o The RRSIG RR's TTL as received in the response; - o The value in the RRSIG RR's Original TTL field; and - o The difference of the RRSIG RR's Signature Expiration time and the - current time. - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the validator has verified the signature as described in Section - 5.3, it must take additional steps to verify the non-existence of an - exact match or closer wildcard match for the query. Section 5.4 - discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4 Authenticated Denial of Existence - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Denial of existence is determined by the following rules: - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - - - -Arends, et al. Expires January 13, 2005 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with - the requested name exist in the zone. However, it is possible - that a wildcard could be used to match the requested RR owner name - and type, so proving that the requested RRset does not exist also - requires proving that no possible wildcard RRset exists that could - have been used to generate a positive response. - - In addition, security-aware resolvers MUST authenticate the NSEC - RRsets that comprise the non-existence proof as described in Section - 5.3. - - To prove non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a validated NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a validator MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Resolver Behavior When Signatures Do Not Validate - - If for whatever reason none of the RRSIGs can be validated, the - response SHOULD be considered BAD. If the validation was being done - to service a recursive query, the name server MUST return RCODE 2 to - the originating client. However, it MUST return the full response if - and only if the original query had the CD bit set. See also Section - 4.7 on caching responses that do not validate. - -5.6 Authentication Example - - Appendix C shows an example the authentication process. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The additional IANA - considerations discussed in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655] and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general - security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the - DNSSEC resource record types. - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection which DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Section 3.2.2 and Section 4.9 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, - since recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will need to pay close attention to the - behavior of the applications which use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidentally denying service to the clients it - is intended to support. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -9. References - -9.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-10 (work in progress), May - 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-08 (work in progress), - May 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, August 1999. - - [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC - 3225, December 2001. - - [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver - message size requirements", RFC 3226, December 2001. - -9.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - - - -Arends, et al. Expires January 13, 2005 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - 2004. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - -Arends, et al. Expires January 13, 2005 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB - 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE - VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO - 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM - W6OISukd1EQt7a0kygkg+PEDxdI= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - 3600 DNSKEY 256 3 5 ( - AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV - rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e - k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo - vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI - - - -Arends, et al. Expires January 13, 2005 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== - ) - 3600 DNSKEY 257 3 5 ( - AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl - LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ - syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP - RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT - Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 9465 example. - ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ - xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ - XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 - hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY - NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z - DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri - bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp - eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk - 7z5OXogYVaFzHKillDt3HRxHIZM= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba - U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 - 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I - BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g - sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - - - -Arends, et al. Expires January 13, 2005 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l - e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh - ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 - AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw - FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG - CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p - P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN - 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL - AhS+JOVfDI/79QtyTI0SaDWcg8U= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - - - -Arends, et al. Expires January 13, 2005 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE - VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb - 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH - l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw - Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - - - -Arends, et al. Expires January 13, 2005 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK - vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E - mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI - NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e - IjgiM8PXkBQtxPq37wDKALkyn7Q= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia - t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj - q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq - GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb - +gLcMZBnHJ326nb/TOOmrqNmQQE= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 - t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq - BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 - 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ - RgNvuwbioFSEuv2pNlkq0goYxNY= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - - - -Arends, et al. Expires January 13, 2005 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY - 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k - mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi - asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W - GghLahumFIpg4MO3LS/prgzVVWo= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key which should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry "*.w.example". Note that the name - "*.w.example" is used in constructing NSEC chains, and that the RRSIG - covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1 Answer - - A successful query to an authoritative server. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( - 20040409183619 38519 example. - Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 - XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP - H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I - kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 - jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP - 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa - 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y - VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx - kbIDV6GPPSZVusnZU6OMgdgzHV4= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C - - - -Arends, et al. Expires January 13, 2005 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z - ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr - U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ - xS9cL2QgW7FChw16mzlkH6/vsfs= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet - 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 - im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ - +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK - v/iVXSYC0b7mPSU+EOlknFpVECs= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq - Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu - yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO - 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq - rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) - - -B.2 Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - - - -Arends, et al. Expires January 13, 2005 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - -B.3 No Data Error - - A "no data" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 - 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB - jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq - ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 - IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) - - ;; Additional - ;; (empty) - - -B.4 Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 DS 57855 5 1 ( - B6DCD485719ADCA18E5F3D48A2331627FDD3 - 636B ) - a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ - oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH - kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD - EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ - Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - -B.5 Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx - 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS - xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs - 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ - vhRXgWT7OuFXldoCG6TfVFMs9xE= ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - -B.6 Wildcard Expansion - - A successful query which was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC RR proves that no - closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 - f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc - tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X - TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw - 4kX18MMR34i8lC36SR5xBni8vHI= ) - - ;; Authority - - - -Arends, et al. Expires January 13, 2005 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd - EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf - 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 - RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 - 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B - ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd - hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u - ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy - 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK - kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh - 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T - cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 - sZM6QjBBLmukH30+w1z3h8PUP2o= ) - - -B.7 Wildcard No Data Error - - A "no data" response for a name covered by a wildcard. The NSEC RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - - - -Arends, et al. Expires January 13, 2005 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( - 20040409183619 38519 example. - OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp - ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg - xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX - a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr - QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( - 20040409183619 38519 example. - r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 - HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU - 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx - 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 - s1InQ2UoIv6tJEaaKkP701j8OLA= ) - - ;; Additional - ;; (empty) - - -B.8 DS Child Zone No Data Error - - A "no data" response for a QTYPE=DS query which was mistakenly sent - to a name server for the child zone. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1081539377 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h - 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF - vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW - DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB - jV7j86HyQgM5e7+miRAz8V01b0I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( - 20040409183619 38519 example. - O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm - FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V - Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW - SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm - jfFJ5arXf4nPxp/kEowGgBRzY/U= ) - - ;; Additional - ;; (empty) - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1 Authenticating An Answer - - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset - was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The resolver needs the corresponding DNSKEY RR in order to - authenticate this answer. The discussion below describes how a - resolver might obtain this DNSKEY RR. - - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 3 indicates the answer was not - the result of wildcard expansion. The "x.w.example.com" MX RRset is - placed in canonical form and, assuming the current time falls between - the signature inception and expiration dates, the signature is - authenticated. - -C.1.1 Authenticating the example DNSKEY RR - - This example shows the logical authentication process that starts - from the a configured root DNSKEY (or DS RR) and moves down the tree - to authenticate the desired "example" DNSKEY RR. Note the logical - order is presented for clarity and an implementation may choose to - construct the authentication as referrals are received or may choose - to construct the authentication chain only after all RRsets have been - obtained, or in any other combination it sees fit. The example here - demonstrates only the logical process and does not dictate any - implementation rules. - - We assume the resolver starts with an configured DNSKEY RR for the - root zone (or a configured DS RR for the root zone). The resolver - checks this configured DNSKEY RR is present in the root DNSKEY RRset - (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this - DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the DNSKEY - RRset are considered authenticated. The resolver then uses one (or - more) of the root DNSKEY RRs to authenticate the "example" DS RRset. - Note the resolver may need to query the root zone to obtain the root - DNSKEY RRset or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - - - -Arends, et al. Expires January 13, 2005 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - matching "example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the "example" - DNSKEY RRset are considered authenticated. - - Finally the resolver checks that some DNSKEY RR in the "example" - DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This - DNSKEY is used to authenticated the RRSIG included in the response. - If multiple "example" DNSKEY RRs match this algorithm and key tag, - then each DNSKEY RR is tried and the answer is authenticated if any - of the matching DNSKEY RRs validates the signature as described - above. - -C.2 Name Error - - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3 No Data Error - - The query in section Appendix B.3 returned an NSEC RR that proves the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4 Referral to Signed Zone - - The query in section Appendix B.4 returned a referral to the signed - "a.example." zone. The DS RR is authenticated in a manner identical - to that of the MX RRset discussed above. This DS RR is used to - authenticate the "a.example" DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "a.example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the - "a.example" DNSKEY RRset are considered authenticated. - -C.5 Referral to Unsigned Zone - - The query in section Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - - - -Arends, et al. Expires January 13, 2005 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - - "example" to "b.example" and the NSEC RR is authenticated in a manner - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion - - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as - the similar to The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 38519. - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 2 indicates the answer the - result of wildcard expansion since the "a.z.w.example" name contains - 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", - the MX RRset is placed in canonical form and, assuming the current - time falls between the signature inception and expiration dates, the - signature is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7 Wildcard No Data Error - - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8 DS Child Zone No Data Error - - The query in section Appendix B.8 returned NSEC RRs that shows the - requested was answered by a child server ("example" server). The - NSEC RR indicates the presence of an SOA RR, showing the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 13, 2005 [Page 57] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt deleted file mode 100644 index 79a17284357cf..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-records-09.txt +++ /dev/null @@ -1,1849 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: January 13, 2005 R. Austein - ISC - M. Larson - VeriSign - D. Massey - USC/ISI - S. Rose - NIST - July 15, 2004 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-09 - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 13, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document is part of a family of documents that describes the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - - - -Arends, et al. Expires January 13, 2005 [Page 1] - -Internet-Draft DNSSEC Resource Records July 2004 - - - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 5 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 5 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 5 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 6 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 6 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 6 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 6 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 6 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 7 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 8 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 8 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 9 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 9 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 9 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 10 - 3.1.5 Signature Expiration and Inception Fields . . . . . . 10 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 10 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 11 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 11 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 12 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 12 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 14 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 14 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 14 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 15 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 16 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 16 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 16 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 18 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 18 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 19 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 19 - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 19 - - - -Arends, et al. Expires January 13, 2005 [Page 2] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 19 - 5.2 Processing of DS RRs When Validating Responses . . . . . . 19 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 20 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 20 - 6. Canonical Form and Order of Resource Records . . . . . . . . . 21 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 21 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 21 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 - 10.2 Informative References . . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 29 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 29 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 29 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 30 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 31 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 32 - Intellectual Property and Copyright Statements . . . . . . . . 33 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 3] - -Internet-Draft DNSSEC Resource Records July 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in [RFC1034], [RFC1035] and subsequent RFCs that update - them: [RFC2136], [RFC2181] and [RFC2308]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]; the reader is - assumed to be familiar with this document. A description of DNS - protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. - - This document defines the DNSSEC resource records. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 4] - -Internet-Draft DNSSEC Resource Records July 2004 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys and MUST NOT be used to store certificates or public keys - that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1 DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner - name MUST be the name of a zone. If bit 7 has value 0, then the - DNSKEY record holds some other type of DNS public key and MUST NOT be - used to verify RRSIGs that cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a - key intended for use as a secure entry point. This flag is only - - - -Arends, et al. Expires January 13, 2005 [Page 5] - -Internet-Draft DNSSEC Resource Records July 2004 - - - intended to be to a hint to zone signing or debugging software as to - the intended use of this DNSKEY record; validators MUST NOT alter - their behavior during the signature validation process in any way - based on the setting of this bit. This also means a DNSKEY RR with - the SEP bit set would also need the Zone Key flag set in order to - legally be able to generate signatures. A DNSKEY RR with the SEP set - and the Zone Key flag not set MUST NOT be used to verify RRSIGs that - cover RRsets. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR, and MUST be ignored upon reception. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 3 and the DNSKEY RR MUST be - treated as invalid during signature verification if found to be some - value other than 3. - -2.1.3 The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and are described in - separate documents. - -2.1.5 Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2 The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer. - Given the currently defined flags, the possible values are: 0, 256, - or 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic as specified in Appendix A.1. - - - -Arends, et al. Expires January 13, 2005 [Page 6] - -Internet-Draft DNSSEC Resource Records July 2004 - - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see [RFC3548]. - -2.3 DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 7] - -Internet-Draft DNSSEC Resource Records July 2004 - - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator - can use these RRSIG RRs to authenticate RRsets from the zone. The - RRSIG RR MUST only be used to carry verification material (digital - signatures) used to secure DNS operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - validator can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034] that stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a signed - zone. - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR MUST match the TTL value of the RRset it - covers. This is an exception to the [RFC2181] rules for TTL values - of individual RRs within a RRset: individual RRSIG with the same - owner name will have different TTL values if the RRsets they cover - have different TTL values. - -3.1 RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 8] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset that is - covered by this RRSIG record. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that a validator - uses it to determine if the answer was synthesized from a wildcard. - If so, it can be used to determine what owner name was used in - generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will need to reconstruct the original owner name in order - to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] - describes how to use the Labels field to reconstruct the original - owner name. - - - -Arends, et al. Expires January 13, 2005 [Page 9] - -Internet-Draft DNSSEC Resource Records July 2004 - - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when generating or verifying the signature. - -3.1.4 Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a validator requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic" as defined in [RFC1982]. As a direct consequence, - the values contained in these fields cannot refer to dates more than - 68 years in either the past or the future. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature, in network byte order. Appendix B explains - how to calculate Key Tag values. - - - -Arends, et al. Expires January 13, 2005 [Page 10] - -Internet-Draft DNSSEC Resource Records July 2004 - - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR which a validator is supposed to use to validate this signature. - The Signer's Name field MUST contain the name of the zone of the - covered RRset. A sender MUST NOT use DNS name compression on the - Signer's Name field when transmitting a RRSIG RR. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature that covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use and these formats are described in separate companion documents. - -3.1.8.1 Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | type | class | TTL | RDATA length | RDATA - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - Any DNS names in the RDATA field of each RR MUST be in - - - -Arends, et al. Expires January 13, 2005 [Page 11] - -Internet-Draft DNSSEC Resource Records July 2004 - - - canonical form; and - - The RRset MUST be sorted in canonical order. - - See Section 6.2 and Section 6.3 for details on canonical form and - ordering of RRsets. - -3.2 The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field is represented as a RR type mnemonic. When - the mnemonic is not known, the TYPE representation as described in - [RFC3597] (section 5) MUST be used. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented either as seconds since 1 January 1970 00:00:00 UTC or in - the form YYYYMMDDHHmmSS in UTC, where: - YYYY is the year (0001-9999, but see Section 3.1.5); - MM is the month number (01-12); - DD is the day of the month (01-31); - HH is the hour in 24 hours notation (00-23); - mm is the minute (00-59); and - SS is the second (00-59). - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. See - Section 2.2. - -3.3 RRSIG RR Example - - The following RRSIG RR stores the signature for the A RRset of - host.example.com: - - - - -Arends, et al. Expires January 13, 2005 [Page 12] - -Internet-Draft DNSSEC Resource Records July 2004 - - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicate that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone DNSKEY RR whose algorithm is - 5 and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 13] - -Internet-Draft DNSSEC Resource Records July 2004 - - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the next owner - name (in the canonical ordering of the zone) which contains - authoritative data or a delegation point NS RRset, and the set of RR - types present at the NSEC RR's owner name. The complete set of NSEC - RRs in a zone both indicate which authoritative RRsets exist in a - zone and also form a chain of authoritative owner names in the zone. - This information is used to provide authenticated denial of existence - for DNS data, as described in [I-D.ietf-dnsext-dnssec-protocol]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034] that - stated that if a CNAME is present for a name, it is the only type - allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist - for the same name as a CNAME resource record in a signed zone. - - See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone - signer determines precisely which NSEC RRs it needs to include in a - zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [RFC2308]. - -4.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain field contains the next owner name (in the canonical - ordering of the zone) which has authoritative data or contains a - delegation point NS RRset; see Section 6.1 for an explanation of - canonical ordering. The value of the Next Domain Name field in the - - - -Arends, et al. Expires January 13, 2005 [Page 14] - -Internet-Draft DNSSEC Resource Records July 2004 - - - last NSEC record in the zone is the name of the zone apex (the owner - name of the zone's SOA RR). This indicates that the owner name of - the NSEC RR is the last name in the canonical ordering of the zone. - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -4.1.2 The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC RR's owner name. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that - has at least one active RR type is encoded using a single octet - window number (from 0 to 255), a single octet bitmap length (from 1 - to 32) indicating the number of octets used for the window block's - bitmap, and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set, - it indicates that an RRset of that type is present for the NSEC RR's - owner name. If a bit is clear, it indicates that no RRset of that - type is present for the NSEC RR's owner name. - - Bits representing pseudo-types MUST be clear, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - - - -Arends, et al. Expires January 13, 2005 [Page 15] - -Internet-Draft DNSSEC Resource Records July 2004 - - - interpreted as zero octets. - - The bitmap for the NSEC RR at a delegation point requires special - attention. Bits corresponding to the delegation NS RRset and the RR - types for which the parent zone has authoritative data MUST be set; - bits corresponding to any non-NS RRset for which the parent is not - authoritative MUST be clear. - - A zone MUST NOT include an NSEC RR for any domain name that only - holds glue records. - -4.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards - on authenticated denial of existence. - -4.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - as described in [RFC3597] (section 5) MUST be used. - -4.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - - - - -Arends, et al. Expires January 13, 2005 [Page 16] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the validator can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [I-D.ietf-dnsext-dnssec-protocol]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 17] - -Internet-Draft DNSSEC Resource Records July 2004 - - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing, but introduces special response - processing requirements for the DS RR; these are described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a one - octet Algorithm field, a one octet Digest Type field, and a Digest - field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 18] - -Internet-Draft DNSSEC Resource Records July 2004 - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record, in network byte order. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the - algorithm number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of writing, the only defined digest - algorithm is SHA-1, which produces a 20 octet digest. - -5.2 Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - - - -Arends, et al. Expires January 13, 2005 [Page 19] - -Internet-Draft DNSSEC Resource Records July 2004 - - - have Flags bit 7 set. If the DNSKEY flags do not indicate a DNSSEC - zone key, the DS RR (and DNSKEY RR it references) MUST NOT be used in - the validation process. - -5.3 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4 DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 20] - -Internet-Draft DNSSEC Resource Records July 2004 - - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required to construct and verify RRSIG RRs. - -6.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - names ending "z.example". The names within each level are sorted in - the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - - -6.2 Canonical RR Form - - For purposes of DNS security, the canonical form of an RR is the wire - format of the RR where: - 1. Every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - 2. All uppercase US-ASCII letters in the owner name of the RR are - replaced by the corresponding lowercase US-ASCII letters; - - - - -Arends, et al. Expires January 13, 2005 [Page 21] - -Internet-Draft DNSSEC Resource Records July 2004 - - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - 4. If the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - 5. The RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with the same owner name, class, - and type are sorted by treating the RDATA portion of the canonical - form of each RR as a left-justified unsigned octet sequence where the - absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs when - putting the RRset in canonical form, the implementation MUST treat - this as a protocol error. If the implementation chooses to handle - this protocol error in the spirit of the robustness principle (being - liberal in what it accepts), the implementation MUST remove all but - one of the duplicate RR(s) for purposes of calculating the canonical - form of the RRset. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 22] - -Internet-Draft DNSSEC Resource Records July 2004 - - -7. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by previous specifications. However, since the evolution of - DNSSEC has been long and somewhat convoluted, this section attempts - to describe the current state of the IANA registries and other - protocol parameters which are (or once were) related to DNSSEC. - - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, - and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [RFC3755] also marked type 30 (NXT) as Obsolete, and restricted - use of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction - security protocol described in [RFC2931] and the transaction KEY - Resource Record described in [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers, and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] - altered this registry to include flags for each entry regarding - its use with the DNS security extensions. Each algorithm entry - could refer to an algorithm that can be used for zone signing, - transaction security (see [RFC2931]) or both. Values 6-251 are - available for assignment by IETF standards action. See Appendix A - for a full listing of the DNS Security Algorithm Numbers entries - at the time of writing and their status of use in DNSSEC. - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] re-assigned all values other than 3 - to reserved and closed this IANA registry. The registry remains - closed, and all KEY and DNSKEY records are required to have - Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by - IETF Standards Action. - - - - -Arends, et al. Expires January 13, 2005 [Page 23] - -Internet-Draft DNSSEC Resource Records July 2004 - - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions, and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] - and [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations related to the use of these records. - - The DS record points to a DNSKEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing such a matching DNSKEY depends on the - type of digest algorithm in use. The only currently defined digest - algorithm is SHA-1, and the working group believes that constructing - a public key which would match the algorithm, key tag, and SHA-1 - digest given in a DS record would be a sufficiently difficult problem - that such an attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation which uses only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. - - The table of algorithms in Appendix A and the key tag calculation - algorithms in Appendix B include the RSA/MD5 algorithm for - completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as - explained in [RFC3110]. - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 24] - -Internet-Draft DNSSEC Resource Records July 2004 - - -9. Acknowledgments - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 25] - -Internet-Draft DNSSEC Resource Records July 2004 - - -10. References - -10.1 Normative References - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-10 (work in progress), May - 2004. - - [I-D.ietf-dnsext-dnssec-protocol] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in - progress), May 2004. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - - - -Arends, et al. Expires January 13, 2005 [Page 26] - -Internet-Draft DNSSEC Resource Records July 2004 - - - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data - Encodings", RFC 3548, July 2003. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", RFC 3755, April 2004. - - [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure - Entry Point Flag", RFC 3757, April 2004. - -10.2 Informative References - - [I-D.ietf-dnsext-nsec-rdata] - Schlyter, J., "DNSSEC NSEC RDATA Format", - draft-ietf-dnsext-nsec-rdata-06 (work in progress), May - 2004. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 27] - -Internet-Draft DNSSEC Resource Records July 2004 - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 28] - -Internet-Draft DNSSEC Resource Records July 2004 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify - the security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs as described in [RFC2931] - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - -A.1.1 Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - - - -Arends, et al. Expires January 13, 2005 [Page 29] - -Internet-Draft DNSSEC Resource Records July 2004 - - - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use and the remainder of the public key area - is determined by that algorithm. Entities should only use domain - names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 30] - -Internet-Draft DNSSEC Resource Records July 2004 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but - it does not uniquely identify a DNSKEY record. Implementations MUST - NOT assume that the key tag uniquely identifies a DNSKEY RR. - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First the - RDATA (in wire format) is treated as a series of 2 octet groups, - these groups are then added together ignoring any carry bits. - - A reference implementation of the key tag algorithm is as an ANSI C - function is given below with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 31] - -Internet-Draft DNSSEC Resource Records July 2004 - - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - -Arends, et al. Expires January 13, 2005 [Page 32] - -Internet-Draft DNSSEC Resource Records July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Arends, et al. Expires January 13, 2005 [Page 33] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt deleted file mode 100644 index 4cfd417804d3d..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-insensitive-04.txt +++ /dev/null @@ -1,639 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd -Clarifies STD0013 Motorola Laboratories -Expires December 2004 July 2004 - - - - Domain Name System (DNS) Case Insensitivity Clarification - ------ ---- ------ ----- ---- ------------- ------------- - <draft-ietf-dnsext-insensitive-04.txt> - - Donald E. Eastlake 3rd - - - -Status of This Document - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group at namedroppers@ops.ietf.org. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. Internet-Drafts are - working documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- - Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - -Abstract - - Domain Name System (DNS) names are "case insensitive". This document - explains exactly what that means and provides a clear specification - of the rules. This clarification should not have any interoperability - consequences. - - - - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Acknowledgements - - The contributions to this document of Rob Austein, Olafur - Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, - Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully - acknowledged. - - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - - Acknowledgements...........................................2 - Table of Contents..........................................2 - - 1. Introduction............................................3 - 2. Case Insensitivity of DNS Labels........................3 - 2.1 Escaping Unusual DNS Label Octets......................3 - 2.2 Example Labels with Escapes............................4 - 3. Name Lookup, Label Types, and CLASS.....................4 - 3.1 Original DNS Label Types...............................5 - 3.2 Extended Label Type Case Insensitivity Considerations..5 - 3.3 CLASS Case Insensitivity Considerations................5 - 4. Case on Input and Output................................6 - 4.1 DNS Output Case Preservation...........................6 - 4.2 DNS Input Case Preservation............................6 - 5. Internationalized Domain Names..........................7 - 6. Security Considerations.................................7 - - Copyright and Disclaimer...................................9 - Normative References.......................................9 - Informative References....................................10 - -02 to -03 Changes........................................10 - -03 to -04 Changes........................................11 - Author's Address..........................................11 - Expiration and File Name..................................11 - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT DNS Case Insensitivity - - -1. Introduction - - The Domain Name System (DNS) is the global hierarchical replicated - distributed database system for Internet addressing, mail proxy, and - other information. Each node in the DNS tree has a name consisting of - zero or more labels [STD 13][RFC 1591, 2606] that are treated in a - case insensitive fashion. This document clarifies the meaning of - "case insensitive" for the DNS. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC 2119]. - - - -2. Case Insensitivity of DNS Labels - - DNS was specified in the era of [ASCII]. DNS names were expected to - look like most host names or Internet email address right halves (the - part after the at-sign, "@") or be numeric as in the in-addr.arpa - part of the DNS name space. For example, - - foo.example.net. - aol.com. - www.gnu.ai.mit.edu. - or 69.2.0.192.in-addr.arpa. - - Case varied alternatives to the above would be DNS names like - - Foo.ExamplE.net. - AOL.COM. - WWW.gnu.AI.mit.EDU. - or 69.2.0.192.in-ADDR.ARPA. - - However, the individual octets of which DNS names consist are not - limited to valid ASCII character codes. They are 8-bit bytes and all - values are allowed. Many applications, however, interpret them as - ASCII characters. - - - -2.1 Escaping Unusual DNS Label Octets - - In Master Files [STD 13] and other human readable and writable ASCII - contexts, an escape is needed for the byte value for period (0x2E, - ".") and all octet values outside of the inclusive range of 0x21 - ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in - the two inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF. - - One typographic convention for octets that do not correspond to an - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT DNS Case Insensitivity - - - ASCII printing graphic is to use a back-slash followed by the value - of the octet as an unsigned integer represented by exactly three - decimal digits. - - The same convention can be used for printing ASCII characters so that - they will be treated as a normal label character. This includes the - back-slash character used in this convention itself which can be - expressed as \092 or \\ and the special label separator period (".") - which can be expressed as and \046 or \. respectively. It is - advisable to avoid using a backslash to quote an immediately - following non-printing ASCII character code to avoid implementation - difficulties. - - A back-slash followed by only one or two decimal digits is undefined. - A back-slash followed by four decimal digits produces two octets, the - first octet having the value of the first three digits considered as - a decimal number and the second octet being the character code for - the fourth decimal digit. - - - -2.2 Example Labels with Escapes - - The first example below shows embedded spaces and a period (".") - within a label. The second one show a 5 octet label where the second - octet has all bits zero, the third is a backslash, and the fourth - octet has all bits one. - - Donald\032E\.\032Eastlake\0323rd.example. - and a\000\\\255z.example. - - - -3. Name Lookup, Label Types, and CLASS - - The design decision was made that comparisons on name lookup for DNS - queries should be case insensitive [STD 13]. That is to say, a lookup - string octet with a value in the inclusive range of 0x41 to 0x5A, the - upper case ASCII letters, MUST match the identical value and also - match the corresponding value in the inclusive range 0x61 to 0x7A, - the lower case ASCII letters. And a lookup string octet with a lower - case ASCII letter value MUST similarly match the identical value and - also match the corresponding value in the upper case ASCII letter - range. - - (Historical Note: the terms "upper case" and "lower case" were - invented after movable type. The terms originally referred to the - two font trays for storing, in partitioned areas, the different - physical type elements. Before movable type, the nearest equivalent - terms were "majuscule" and "minuscule".) - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT DNS Case Insensitivity - - - One way to implement this rule would be, when comparing octets, to - subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A - before the comparison. Such an operation is commonly known as "case - folding" but implementation via case folding is not required. Note - that the DNS case insensitivity does NOT correspond to the case - folding specified in iso-8859-1 or iso-8859-2. For example, the - octets 0xDD (\221) and 0xFD (\253) do NOT match although in other - contexts, where they are interpreted as the upper and lower case - version of "Y" with an acute accent, they might. - - - -3.1 Original DNS Label Types - - DNS labels in wire encoded names have a type associated with them. - The original DNS standard [RFC 1035] had only two types. ASCII - labels, with a length of from zero to 63 octets, and indirect labels - which consist of an offset pointer to a name location elsewhere in - the wire encoding on a DNS message. (The ASCII label of length zero - is reserved for use as the name of the root node of the name tree.) - ASCII labels follow the ASCII case conventions described herein and, - as stated above, can actually contain arbitrary byte values. Indirect - labels are, in effect, replaced by the name to which they point which - is then treated with the case insensitivity rules in this document. - - - -3.2 Extended Label Type Case Insensitivity Considerations - - DNS was extended by [RFC 2671] to have additional label type numbers - available. (The only such type defined so far is the BINARY type [RFC - 2673].) - - The ASCII case insensitivity conventions only apply to ASCII labels, - that is to say, label type 0x0, whether appearing directly or invoked - by indirect labels. - - - -3.3 CLASS Case Insensitivity Considerations - - As described in [STD 13] and [RFC 2929], DNS has an additional axis - for data location called CLASS. The only CLASS in global use at this - time is the "IN" or Internet CLASS. - - The handling of DNS label case is not CLASS dependent. - - - - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT DNS Case Insensitivity - - -4. Case on Input and Output - - While ASCII label comparisons are case insensitive, [STD 13] says - case MUST be preserved on output, and preserved when convenient on - input. However, this means less than it would appear since the - preservation of case on output is NOT required when output is - optimized by the use of indirect labels, as explained below. - - - -4.1 DNS Output Case Preservation - - [STD 13] views the DNS namespace as a node tree. ASCII output is as - if a name was marshaled by taking the label on the node whose name is - to be output, converting it to a typographically encoded ASCII - string, walking up the tree outputting each label encountered, and - preceding all labels but the first with a period ("."). Wire output - follows the same sequence but each label is wire encoded and no - periods inserted. No "case conversion" or "case folding" is done - during such output operations, thus "preserving" case. However, to - optimize output, indirect labels may be used to point to names - elsewhere in the DNS answer. In determining whether the name to be - pointed to, for example the QNAME, is the "same" as the remainder of - the name being optimized, the case insensitive comparison specified - above is done. Thus such optimization MAY easily destroy the output - preservation of case. This type of optimization is commonly called - "name compression". - - - -4.2 DNS Input Case Preservation - - Originally, DNS input came from an ASCII Master File as defined in - [STD 13] or a zone transfer. DNS Dynamic update and incremental zone - transfers [RFC 1995] have been added as a source of DNS data [RFC - 2136, 3007]. When a node in the DNS name tree is created by any of - such inputs, no case conversion is done. Thus the case of ASCII - labels is preserved if they are for nodes being created. However, - when a name label is input for a node that already exist in DNS data - being held, the situation is more complex. Implementations may retain - the case first input for such a label or allow new input to override - the old case or even maintain separate copies preserving the input - case. - - For example, if data with owner name "foo.bar.example" is input and - then later data with owner name "xyz.BAR.example" is input, the name - of the label on the "bar.example" node, i.e. "bar", might or might - not be changed to "BAR" or the actual input case could be preserved. - Thus later retrieval of data stored under "xyz.bar.example" in this - case can easily return data with "xyz.BAR.example". The same - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT DNS Case Insensitivity - - - considerations apply when inputting multiple data records with owner - names differing only in case. For example, if an "A" record is stored - as the first resourced record under owner name "xyz.BAR.example" and - then a second "A" record is stored under "XYZ.BAR.example", the - second MAY be stored with the first (lower case initial label) name - or the second MAY override the first so that only an upper case - initial label is retained or both capitalizations MAY be kept. - - Note that the order of insertion into a server database of the DNS - name tree nodes that appear in a Master File is not defined so that - the results of inconsistent capitalization in a Master File are - unpredictable output capitalization. - - - -5. Internationalized Domain Names - - A scheme has been adopted for "internationalized domain names" and - "internationalized labels" as described in [RFC 3490, 3454, 3491, and - 3492]. It makes most of [UNICODE] available through a separate - application level transformation from internationalized domain name - to DNS domain name and from DNS domain name to internationalized - domain name. Any case insensitivity that internationalized domain - names and labels have varies depending on the script and is handled - entirely as part of the transformation described in [RFC 3454] and - [RFC 3491] which should be seen for further details. This is not a - part of the DNS as standardized in STD 13. - - - -6. Security Considerations - - The equivalence of certain DNS label types with case differences, as - clarified in this document, can lead to security problems. For - example, a user could be confused by believing two domain names - differing only in case were actually different names. - - Furthermore, a domain name may be used in contexts other than the - DNS. It could be used as a case sensitive index into some data base - system. Or it could be interpreted as binary data by some integrity - or authentication code system. These problems can usually be handled - by using a standardized or "canonical" form of the DNS ASCII type - labels, that is, always mapping the ASCII letter value octets in - ASCII labels to some specific pre-chosen case, either upper case or - lower case. An example of a canonical form for domain names (and also - a canonical ordering for them) appears in Section 8 of [RFC 2535]. - See also [RFC 3597]. - - Finally, a non-DNS name may be stored into DNS with the false - expectation that case will always be preserved. For example, although - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT DNS Case Insensitivity - - - this would be quite rare, on a system with case sensitive email - address local parts, an attempt to store two "RP" records that - differed only in case would probably produce unexpected results that - might have security implications. That is because the entire email - address, including the possibly case sensitive local or left hand - part, is encoded into a DNS name in a readable fashion where the case - of some letters might be changed on output as described above. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78, and except - as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Normative References - - [ASCII] - ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, 1968. - - [RFC 1034, 1035] - See [STD 13]. - - [RFC 1995] - M. Ohta, "Incremental Zone Transfer in DNS", August - 1996. - - [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - - [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997. - - [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic - Update", November 2000. - - [RFC 3597] - Andreas Gustafsson, "Handling of Unknown DNS RR Types", - draft-ietf-dnsext-unknown-rrs-05.txt, March 2003. - - [STD 13] - - P. Mockapetris, "Domain names - concepts and facilities", RFC - 1034, November 1987. - - P. Mockapetris, "Domain names - implementation and - specification", RFC 1035, November 1987. - - - - - - -D. Eastlake 3rd [Page 9] - - -INTERNET-DRAFT DNS Case Insensitivity - - -Informative References - - [RFC 1591] - J. Postel, "Domain Name System Structure and - Delegation", March 1994. - - [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain - Name System (DNS) IANA Considerations", September 2000. - - [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August - 1999. - - [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", - August 1999. - - [RFC 3092] - D. Eastlake 3rd, C. Manros, E. Raymond, "Etymology of - Foo", 1 April 2001. - - [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of - Internationalized String ("stringprep")", December 2002. - - [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", March 2003. - - [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile - for Internationalized Domain Names (IDN)", March 2003. - - [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode - for Internationalized Domain Names in Applications (IDNA)", March - 2003. - - [UNICODE] - The Unicode Consortium, "The Unicode Standard", - <http://www.unicode.org/unicode/standard/standard.html>. - - - --02 to -03 Changes - - The following changes were made between draft version -02 and -03: - - 1. Add internationalized domain name section and references. - - 2. Change to indicate that later input of a label for an existing DNS - name tree node may or may not be normalized to the earlier input or - override it or both may be preserved. - - 3. Numerous minor wording changes. - - - -D. Eastlake 3rd [Page 10] - - -INTERNET-DRAFT DNS Case Insensitivity - - --03 to -04 Changes - - The following changes were made between draft version -03 and -04: - - 1. Change to conform to the new IPR, Copyright, etc., notice - requirements. - - 2. Change in some section headers for clarity. - - 3. Drop section on wildcards. - - 4. Add emphasis on loss of case preservation due to name compression. - - 5. Add references to RFCs 1995 and 3092. - - - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1 508-786-7554 (w) - +1 508-634-2066 (h) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires December 2004. - - Its file name is draft-ietf-dnsext-insensitive-04.txt. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 11] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt deleted file mode 100644 index 123d3cc096118..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-01.txt +++ /dev/null @@ -1,335 +0,0 @@ - -DNS Extensions Working Group J. Schlyter -Internet-Draft August 24, 2004 -Expires: February 22, 2005 - - - RFC 3597 Interoperability Report - draft-ietf-dnsext-interop3597-01.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3667. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on February 22, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 1] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.1 Authoritative Primary Name Server . . . . . . . . . . . . . . 3 - 3.2 Authoritative Secondary Name Server . . . . . . . . . . . . . 3 - 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . . . 3 - 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4 - 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - Normative References . . . . . . . . . . . . . . . . . . . . . 4 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4 - A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5 - Intellectual Property and Copyright Statements . . . . . . . . 6 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 2] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -1. Introduction - - This memo documents the result from the RFC 3597 (Handling of Unknown - DNS Resource Record Types) interoperability testing. The test was - performed during June and July 2004 by request of the IETF DNS - Extensions Working Group. - -2. Implementations - - The following is a list, in alphabetic order, of implementations for - compliance of RFC 3597: - - DNSJava 1.6.4 - ISC BIND 8.4.5rc4 - ISC BIND 9.3.0rc2 - NSD 2.1.1 - Net::DNS 0.47 patchlevel 1 - Nominum ANS 2.2.1.0.d - - These implementations covers the following functions (number of - implementations tested for each function in paranthesis): - - Authoritative Name Servers (4) - Full Recursive Resolver (2) - Stub Resolver (4) - DNSSEC Zone Signers (2) - -3. Tests - -3.1 Authoritative Primary Name Server - - The test zone data (Appendix A) was loaded into the name server - implementation and the server was queried for the loaded information. - -3.2 Authoritative Secondary Name Server - - The test zone data (Appendix A) was transferred using AXFR from - another name server implementation and the server was queried for the - transferred information. - -3.3 Full Recursive Resolver - - A recursive resolver was queried for resource records from a domain - with the test zone data (Appendix A). - -3.4 Stub Resolver - - A stub resolver was used to query resource records from a domain with - - - -Schlyter Expires February 22, 2005 [Page 3] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - - the test zone data (Appendix A). - -3.5 DNSSEC Signer - - A DNSSEC signer was used to sign a zone with test zone data (Appendix - A). - -4. Problems found - - Two implementations had problems with text presentation of zero - length RDATA. - - One implementation had problems with text presentation of RR type - code and classes >= 4096. - - Bug reports were filed for problems found. - -5. Summary - - Unknown type codes works in the tested authoritative servers, - recursive resolvers and stub clients. - - No changes are needed to advance RFC 3597 to draft standard. - -Normative References - - [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - -Author's Address - - Jakob Schlyter - - EMail: jakob@rfc.se - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 4] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Appendix A. Test zone data - - ; A-record encoded as TYPE1 - a TYPE1 \# 4 7f000001 - a TYPE1 192.0.2.1 - a A \# 4 7f000002 - - ; draft-ietf-secsh-dns-05.txt - sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e - - ; bogus test record (from RFC 3597) - type731 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - - ; zero length RDATA (from RFC 3597) - type62347 TYPE62347 \# 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires February 22, 2005 [Page 5] - -Internet-Draft RFC 3597 Interoperability Report August 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the IETF's procedures with respect to rights in IETF Documents can - be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Schlyter Expires February 22, 2005 [Page 6] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-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 6bffb70423f4e..0000000000000 --- 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-33.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt deleted file mode 100644 index 8dcacc8bb9ec2..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-33.txt +++ /dev/null @@ -1,1559 +0,0 @@ - - - - - - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Bernard Aboba -Category: Standards Track Dave Thaler -<draft-ietf-dnsext-mdns-33.txt> Microsoft -18 July 2004 - - - Linklocal Multicast Name Resolution (LLMNR) - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 2, 2005. - -Copyright Notice - - Copyright (C) The Internet Society 2004. All rights reserved. - -Abstract - - Today, with the rise of home networking, there are an increasing - number of ad-hoc networks operating without a Domain Name System - (DNS) server. The goal of Link-Local Multicast Name Resolution - (LLMNR) is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. LLMNR supports all - current and future DNS formats, types and classes, while operating on - a separate port from DNS, and with a distinct resolver cache. Since - LLMNR only operates on the local link, it cannot be considered a - substitute for DNS. - - - - -Esibov, Aboba & Thaler Standards Track [Page 1] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -Table of Contents - -1. Introduction .......................................... 3 - 1.1 Requirements .................................... 4 - 1.2 Terminology ..................................... 4 -2. Name resolution using LLMNR ........................... 4 - 2.1 LLMNR packet format ............................. 6 - 2.2 Sender behavior ................................. 8 - 2.3 Responder behavior .............................. 8 - 2.4 Unicast queries ................................. 11 - 2.5 Off-link detection .............................. 11 - 2.6 Responder responsibilities ...................... 12 - 2.7 Retransmission and jitter ....................... 13 - 2.8 DNS TTL ......................................... 13 - 2.9 Use of the authority and additional sections .... 14 -3. Usage model ........................................... 14 - 3.1 LLMNR configuration ............................. 15 -4. Conflict resolution ................................... 16 - 4.1 Considerations for multiple interfaces .......... 18 - 4.2 API issues ...................................... 19 -5. Security considerations ............................... 20 - 5.1 Scope restriction ............................... 20 - 5.2 Usage restriction ............................... 21 - 5.3 Cache and port separation ....................... 22 - 5.4 Authentication .................................. 22 -6. IANA considerations ................................... 22 -7. References ............................................ 22 - 7.1 Normative References ............................ 22 - 7.2 Informative References .......................... 23 -Acknowledgments .............................................. 24 -Authors' Addresses ........................................... 25 -Intellectual Property Statement .............................. 25 -Disclaimer of Validity ....................................... 26 -Full Copyright Statement ..................................... 26 - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 2] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -1. Introduction - - This document discusses Link Local Multicast Name Resolution (LLMNR), - which utilizes the DNS packet format and supports all current and - future DNS formats, types and classes. LLMNR operates on a separate - port from the Domain Name System (DNS), with a distinct resolver - cache. - - The goal of LLMNR is to enable name resolution in scenarios in which - conventional DNS name resolution is not possible. These include - scenarios in which hosts are not configured with the address of a DNS - server, where configured DNS servers do not reply to a query, or - where they respond with errors, as described in Section 2. Since - LLMNR only operates on the local link, it cannot be considered a - substitute for DNS. - - Link-scope multicast addresses are used to prevent propagation of - LLMNR traffic across routers, potentially flooding the network. - LLMNR queries can also be sent to a unicast address, as described in - Section 2.4. - - Propagation of LLMNR packets on the local link is considered - sufficient to enable name resolution in small networks. The - assumption is that if a network has a gateway, then the network is - able to provide DNS server configuration. Configuration issues are - discussed in Section 3.1. - - In the future, it may be desirable to consider use of multicast name - resolution with multicast scopes beyond the link-scope. This could - occur if LLMNR deployment is successful, the need arises for - multicast name resolution beyond the link-scope, or multicast routing - becomes ubiquitous. For example, expanded support for multicast name - resolution might be required for mobile ad-hoc networking scenarios, - or where no DNS server is available that is authoritative for the - names of local hosts, and can support dynamic DNS, such as in - wireless hotspots. - - Once we have experience in LLMNR deployment in terms of - administrative issues, usability and impact on the network, it will - be possible to reevaluate which multicast scopes are appropriate for - use with multicast name resolution. - - Service discovery in general, as well as discovery of DNS servers - using LLMNR in particular, is outside of the scope of this document, - as is name resolution over non-multicast capable media. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 3] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -1.1. Requirements - - In this document, several words are used to signify the requirements - of the specification. The key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - -1.2. Terminology - - This document assumes familiarity with DNS terminology defined in - [RFC1035]. Other terminology used in this document includes: - -Positively Resolved - Responses with RCODE set to zero are referred to in this document - as "positively resolved". - -Routable Address - An address other than a Link-Local address. This includes globally - routable addresses, as well as private addresses. - -Reachable - An address is considered reachable over a link if either an ARP or - neighbor discovery cache entry exists for the address on the link. - -Responder - A host that listens to LLMNR queries, and responds to those for - which it is authoritative. - -Sender - A host that sends an LLMNR query. - -2. Name resolution using LLMNR - - LLMNR is a peer-to-peer name resolution protocol that is not intended - as a replacement for DNS. LLMNR queries are sent to and received on - port 5355. IPv4 administratively scoped multicast usage is specified - in "Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link- - scope multicast address a given responder listens to, and to which a - sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast - address a given responder listens to, and to which a sender sends all - queries, is FF02:0:0:0:0:0:1:3. - - Typically a host is configured as both an LLMNR sender and a - responder. A host MAY be configured as a sender, but not a - responder. However, a host configured as a responder MUST act as a - sender to verify the uniqueness of names as described in Section 4. - This document does not specify how names are chosen or configured. - - - -Esibov, Aboba & Thaler Standards Track [Page 4] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - This may occur via any mechanism, including DHCPv4 [RFC2131] or - DHCPv6 [RFC3315]. - - LLMNR usage MAY be configured manually or automatically on a per - interface basis. By default, LLMNR responders SHOULD be enabled on - all interfaces, at all times. Enabling LLMNR for use in situations - where a DNS server has been configured will result in a change in - default behavior without a simultaneous update to configuration - information. Where this is considered undesirable, LLMNR SHOULD NOT - be enabled by default, so that hosts will neither listen on the link- - scope multicast address, nor will they send queries to that address. - - An LLMNR sender may send a request for any name. However, by - default, LLMNR requests SHOULD be sent only when one of the following - conditions are met: - - [1] No manual or automatic DNS configuration has been - performed. If an interface has been configured with DNS - server address(es), then LLMNR SHOULD NOT be used as the - primary name resolution mechanism on that interface, although - it MAY be used as a name resolution mechanism of last resort. - - [2] DNS servers do not respond. - - [3] DNS servers respond to a DNS query with RCODE=3 - (Authoritative Name Error) or RCODE=0, and an empty - answer section. - - A typical sequence of events for LLMNR usage is as follows: - - [a] DNS servers are not configured or do not respond to a - DNS query, or respond with RCODE=3, or RCODE=0 and an - empty answer section. - - [b] An LLMNR sender sends an LLMNR query to the link-scope - multicast address(es) defined in Section 2, unless a - unicast query is indicated. A sender SHOULD send LLMNR - queries for PTR RRs via unicast, as specified in Section 2.4. - - [c] A responder responds to this query only if it is authoritative - for the domain name in the query. A responder responds to a - multicast query by sending a unicast UDP response to the sender. - Unicast queries are responded to as indicated in Section 2.4. - - [d] Upon reception of the response, the sender processes it. - - Further details of sender and responder behavior are provided in the - sections that follow. - - - -Esibov, Aboba & Thaler Standards Track [Page 5] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -2.1. LLMNR packet format - - LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 - for both queries and responses. LLMNR implementations SHOULD send - UDP queries and responses only as large as are known to be - permissible without causing fragmentation. When in doubt a maximum - packet size of 512 octets SHOULD be used. LLMNR implementations MUST - accept UDP queries and responses as large as permitted by the link - MTU. - -2.1.1. LLMNR header format - - LLMNR queries and responses utilize the DNS header format defined in - [RFC1035] with exceptions noted below: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ID | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - |QR| Opcode | Z|TC| Z| Z| Z| Z| Z| RCODE | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | QDCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ANCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | NSCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | ARCOUNT | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - where: - -ID A 16 bit identifier assigned by the program that generates any kind - of query. This identifier is copied from the query to the response - and can be used by the sender to match responses to outstanding - queries. The ID field in a query SHOULD be set to a pseudo-random - value. - -QR A one bit field that specifies whether this message is an LLMNR - query (0), or an LLMNR response (1). - -OPCODE - A four bit field that specifies the kind of query in this message. - This value is set by the originator of a query and copied into the - response. This specification defines the behavior of standard - queries and responses (opcode value of zero). Future - specifications may define the use of other opcodes with LLMNR. - - - -Esibov, Aboba & Thaler Standards Track [Page 6] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - LLMNR senders and responders MUST support standard queries (opcode - value of zero). LLMNR queries with unsupported OPCODE values MUST - be silently discarded by responders. - -TC TrunCation - specifies that this message was truncated due to - length greater than that permitted on the transmission channel. - The TC bit MUST NOT be set in an LLMNR query and if set is ignored - by an LLMNR responder. If the TC bit is set an LLMNR response, - then the sender MAY use the response if it contains all necessary - information, or the sender MAY discard the response and resend the - LLMNR query over TCP using the unicast address of the responder as - the destination address. See [RFC2181] and Section 2.4 of this - specification for further discussion of the TC bit. - -Z Reserved for future use. Implementations of this specification - MUST set these bits to zero in both queries and responses. If - these bits are set in a LLMNR query or response, implementations of - this specification MUST ignore them. Since reserved bits could - conceivably be used for different purposes than in DNS, - implementors are advised not to enable processing of these bits in - an LLMNR implementation starting from a DNS code base. - -RCODE - Response code -- this 4 bit field is set as part of LLMNR - responses. In an LLMNR query, the RCODE MUST be zero, and is - ignored by the responder. The response to a multicast LLMNR query - MUST have RCODE set to zero. A sender MUST silently discard an - LLMNR response with a non-zero RCODE sent in response to a - multicast query. - - If an LLMNR responder is authoritative for the name in a multicast - query, but an error is encountered, the responder SHOULD send an - LLMNR response with an RCODE of zero, no RRs in the answer section, - and the TC bit set. This will cause the query to be resent using - TCP, and allow the inclusion of a non-zero RCODE in the response to - the TCP query. Responding with the TC bit set is preferrable to - not sending a response, since it enables errors to be diagnosed. - - Since LLMNR responders only respond to LLMNR queries for names for - which they are authoritative, LLMNR responders MUST NOT respond - with an RCODE of 3; instead, they should not respond at all. - - LLMNR implementations MUST support EDNS0 [RFC2671] and extended - RCODE values. - -QDCOUNT - An unsigned 16 bit integer specifying the number of entries in the - question section. A sender MUST place only one question into the - - - -Esibov, Aboba & Thaler Standards Track [Page 7] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - question section of an LLMNR query. LLMNR responders MUST silently - discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders - MUST silently discard LLMNR responses with QDCOUNT not equal to - one. - -ANCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the answer section. LLMNR responders MUST silently - discard LLMNR queries with ANCOUNT not equal to zero. - -NSCOUNT - An unsigned 16 bit integer specifying the number of name server - resource records in the authority records section. Authority - record section processing is described in Section 2.9. - -ARCOUNT - An unsigned 16 bit integer specifying the number of resource - records in the additional records section. Additional record - section processing is described in Section 2.9. - -2.2. Sender behavior - - A sender may send an LLMNR query for any legal resource record type - (e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. - - As described in Section 2.4, a sender may also send a unicast query. - Sections 2 and 3 describe the circumstances in which LLMNR queries - may be sent. - - The sender MUST anticipate receiving no replies to some LLMNR - queries, in the event that no responders are available within the - link-scope or in the event no positive non-null responses exist for - the transmitted query. If no positive response is received, a - resolver treats it as a response that no records of the specified - type and class exist for the specified name (it is treated the same - as a response with RCODE=0 and an empty answer section). - - Since the responder may order the RRs in the response so as to - indicate preference, the sender SHOULD preserve ordering in the - response to the querying application. - -2.3. Responder behavior - - An LLMNR response MUST be sent to the sender via unicast. - - Upon configuring an IP address responders typically will synthesize - corresponding A, AAAA and PTR RRs so as to be able to respond to - LLMNR queries for these RRs. An SOA RR is synthesized only when a - - - -Esibov, Aboba & Thaler Standards Track [Page 8] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - responder has another RR as well; the SOA RR MUST NOT be the only RR - that a responder has. However, in general whether RRs are manually - or automatically created is an implementation decision. - - For example, a host configured to have computer name "host1" and to - be a member of the "example.com" domain, and with IPv4 address - 10.1.1.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be - authoritative for the following records: - - host1. IN A 10.1.1.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - host1.example.com. IN A 10.1.1.1 - IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 - - 1.1.1.10.in-addr.arpa. IN PTR host1. - IN PTR host1.example.com. - - 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa - IN PTR host1. - IN PTR host1.example.com - - An LLMNR responder might be further manually configured with the name - of a local mail server with an MX RR included in the "host1." and - "host1.example.com." records. - - In responding to queries: - -[a] Responders MUST listen on UDP port 5355 on the link-scope multicast - address(es) defined in Section 2, and on UDP and TCP port 5355 on - the unicast address(es) that could be set as the source address(es) - when the responder responds to the LLMNR query. - -[b] Responders MUST direct responses to the port from which the query - was sent. When queries are received via TCP this is an inherent - part of the transport protocol. For queries received by UDP the - responder MUST take note of the source port and use that as the - destination port in the response. Responses SHOULD always be sent - from the port to which they were directed. - -[c] Responders MUST respond to LLMNR queries for names and addresses - they are authoritative for. This applies to both forward and - reverse lookups. - -[d] Responders MUST NOT respond to LLMNR queries for names they are not - authoritative for. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 9] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[e] Responders MUST NOT respond using cached data. - -[f] If a DNS server is running on a host that supports LLMNR, the DNS - server MUST respond to LLMNR queries only for the RRSets relating - to the host on which the server is running, but MUST NOT respond - for other records for which the server is authoritative. DNS - servers also MUST NOT send LLMNR queries in order to resolve DNS - queries. - -[g] If a responder is authoritative for a name, it MAY respond with - RCODE=0 and an empty answer section, if the type of query does not - match a RR that the responder has. - - As an example, a host configured to respond to LLMNR queries for the - name "foo.example.com." is authoritative for the name - "foo.example.com.". On receiving an LLMNR query for an A RR with the - name "foo.example.com." the host authoritatively responds with A - RR(s) that contain IP address(es) in the RDATA of the resource - record. If the responder has a AAAA RR, but no A RR, and an A RR - query is received, the responder would respond with RCODE=0 and an - empty answer section. - - In conventional DNS terminology a DNS server authoritative for a zone - is authoritative for all the domain names under the zone apex except - for the branches delegated into separate zones. Contrary to - conventional DNS terminology, an LLMNR responder is authoritative - only for the zone apex. - - For example the host "foo.example.com." is not authoritative for the - name "child.foo.example.com." unless the host is configured with - multiple names, including "foo.example.com." and - "child.foo.example.com.". As a result, "foo.example.com." cannot - reply to an LLMNR query for "child.foo.example.com." with RCODE=3 - (authoritative name error). The purpose of limiting the name - authority scope of a responder is to prevent complications that could - be caused by coexistence of two or more hosts with the names - representing child and parent (or grandparent) nodes in the DNS tree, - for example, "foo.example.com." and "child.foo.example.com.". - - In this example (unless this limitation is introduced) an LLMNR query - for an A resource record for the name "child.foo.example.com." would - result in two authoritative responses: RCODE=3 (authoritative name - error) received from "foo.example.com.", and a requested A record - - from "child.foo.example.com.". To prevent this ambiguity, LLMNR - enabled hosts could perform a dynamic update of the parent (or - grandparent) zone with a delegation to a child zone. In this example - a host "child.foo.example.com." would send a dynamic update for the - NS and glue A record to "foo.example.com.", but this approach - - - -Esibov, Aboba & Thaler Standards Track [Page 10] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - significantly complicates implementation of LLMNR and would not be - acceptable for lightweight hosts. - -2.4. Unicast queries and responses - - Unicast queries SHOULD be sent when: - - [a] A sender repeats a query after it received a response - with the TC bit set to the previous LLMNR multicast query, or - - [b] The sender queries for a PTR RR of a fully formed IP address - within the "in-addr.arpa" or "ip6.arpa" zones. - - Unicast LLMNR queries MUST be done using TCP and the responses MUST - be sent using the same TCP connection as the query. Senders MUST - support sending TCP queries, and responders MUST support listening - for TCP queries. If the sender of a TCP query receives a response to - that query not using TCP, the response MUST be silently discarded. - - Unicast UDP queries MUST be silently discarded. - - If TCP connection setup cannot be completed in order to send a - unicast TCP query, this is treated as a response that no records of - the specified type and class exist for the specified name (it is - treated the same as a response with RCODE=0 and an empty answer - section). - -2.5. "Off link" detection - - For IPv4, an "on link" address is defined as a link-local address - [IPv4Link] or an address whose prefix belongs to a subnet on the - local link. For IPv6 [RFC2460] an "on link" address is either a - link-local address, defined in [RFC2373], or an address whose prefix - belongs to a subnet on the local link. - - A sender MUST select a source address for LLMNR queries that is "on - link". The destination address of an LLMNR query MUST be a link- - scope multicast address or an "on link" unicast address. - - A responder MUST select a source address for responses that is "on - link". The destination address of an LLMNR response MUST be an "on - link" unicast address. - - On receiving an LLMNR query, the responder MUST check whether it was - sent to a LLMNR multicast addresses defined in Section 2. If it was - sent to another multicast address, then the query MUST be silently - discarded. - - - - -Esibov, Aboba & Thaler Standards Track [Page 11] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - Section 2.4 discusses use of TCP for LLMNR queries and responses. In - composing an LLMNR query using TCP, the sender MUST set the Hop Limit - field in the IPv6 header and the TTL field in the IPv4 header of the - response to one (1). The responder SHOULD set the TTL or Hop Limit - settings on the TCP listen socket to one (1) so that SYN-ACK packets - will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This - prevents an incoming connection from off-link since the sender will - not receive a SYN-ACK from the responder. - - For UDP queries and responses the Hop Limit field in the IPv6 header, - and the TTL field in the IPV4 header MAY be set to any value. - However, it is RECOMMENDED that the value 255 be used for - compatibility with Apple Rendezvous. - - Implementation note: - - In the sockets API for IPv4 [POSIX], the IP_TTL and - IP_MULTICAST_TTL socket options are used to set the TTL of - outgoing unicast and multicast packets. The IP_RECVTTL socket - option is available on some platforms to retrieve the IPv4 TTL of - received packets with recvmsg(). [RFC2292] specifies similar - options for setting and retrieving the IPv6 Hop Limit. - -2.6. Responder responsibilities - - It is the responsibility of the responder to ensure that RRs returned - in LLMNR responses MUST only include values that are valid on the - local interface, such as IPv4 or IPv6 addresses valid on the local - link or names defended using the mechanism described in Section 4. - In particular: - - [a] If a link-scope IPv6 address is returned in a AAAA RR, - that address MUST be valid on the local link over which - LLMNR is used. - - [b] If an IPv4 address is returned, it MUST be reachable - through the link over which LLMNR is used. - - [c] If a name is returned (for example in a CNAME, MX - or SRV RR), the name MUST be resolvable on the local - link over which LLMNR is used. - - Routable addresses MUST be included first in the response, if - available. This encourages use of routable address(es) for - establishment of new connections. - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 12] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -2.7. Retransmission and jitter - - An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine - when to retransmit an LLMNR query and how long to collect responses - to an LLMNR query. - - If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, - then a sender MAY repeat the transmission of the query in order to - assure that it was received by a host capable of responding to it. - Retransmission of UDP queries SHOULD NOT be attempted more than 3 - times. Where LLMNR queries are sent using TCP, retransmission is - handled by the transport layer. - - Because an LLMNR sender cannot know in advance if a query sent using - multicast will receive no response, one response, or more than one - response, the sender SHOULD wait for LLMNR_TIMEOUT in order to - collect all possible responses, rather than considering the multicast - query answered after the first response is received. A unicast query - sender considers the query answered after the first response is - received, so that it only waits for LLMNR_TIMEOUT if no response has - been received. - - An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT - for each transmission. It is suggested that the computation of - LLMNR_TIMEOUT be based on the response times for earlier LLMNR - queries sent on the same interface. - - For example, the algorithms described in RFC 2988 [RFC2988] - (including exponential backoff) compute an RTO, which is used as the - value of LLMNR_TIMEOUT. Smaller values MAY be used for the initial - RTO (discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum - RTO (discussed in Section 2 of [RFC2988], paragraph 2.4), and the - maximum RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). - - Recommended values are an initial RTO of 1 second, a minimum RTO of - 200ms, and a maximum RTO of 5 seconds. In order to avoid - synchronization, the transmission of each LLMNR query and response - SHOULD delayed by a time randomly selected from the interval 0 to 100 - ms. This delay MAY be avoided by responders responding with RRs - which they have previously determined to be UNIQUE (see Section 4 for - details). - -2.8. DNS TTL - - The responder should use a pre-configured TTL value in the records - returned an LLMNR response. A default value of 30 seconds is - RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc - networks), the TTL value may need to be reduced. - - - -Esibov, Aboba & Thaler Standards Track [Page 13] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - Due to the TTL minimalization necessary when caching an RRset, all - TTLs in an RRset MUST be set to the same value. - -2.9. Use of the authority and additional sections - - Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a - concept of delegation. In LLMNR, the NS resource record type may be - stored and queried for like any other type, but it has no special - delegation semantics as it does in the DNS. Responders MAY have NS - records associated with the names for which they are authoritative, - but they SHOULD NOT include these NS records in the authority - sections of responses. - - Responders SHOULD insert an SOA record into the authority section of - a negative response, to facilitate negative caching as specified in - [RFC2308]. The owner name of this SOA record MUST be equal to the - query name. - - Responders SHOULD NOT perform DNS additional section processing, - except as required for EDNS0 and DNSSEC. - - Senders MUST NOT cache RRs from the authority or additional section - of a response as answers, though they may be used for other purposes - such as negative caching. - -3. Usage model - - Since LLMNR is a secondary name resolution mechanism, its usage is in - part determined by the behavior of DNS implementations. This - document does not specify any changes to DNS resolver behavior, such - as searchlist processing or retransmission/failover policy. However, - robust DNS resolver implementations are more likely to avoid - unnecessary LLMNR queries. - - As noted in [DNSPerf], even when DNS servers are configured, a - significant fraction of DNS queries do not receive a response, or - result in negative responses due to missing inverse mappings or NS - records that point to nonexistent or inappropriate hosts. This has - the potential to result in a large number of unnecessary LLMNR - queries. - - [RFC1536] describes common DNS implementation errors and fixes. If - the proposed fixes are implemented, unnecessary LLMNR queries will be - reduced substantially, and so implementation of [RFC1536] is - recommended. - - For example, [RFC1536] Section 1 describes issues with retransmission - and recommends implementation of a retransmission policy based on - - - -Esibov, Aboba & Thaler Standards Track [Page 14] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - round trip estimates, with exponential backoff. [RFC1536] Section 4 - describes issues with failover, and recommends that resolvers try - another server when they don't receive a response to a query. These - policies are likely to avoid unnecessary LLMNR queries. - - [RFC1536] Section 3 describes zero answer bugs, which if addressed - will also reduce unnecessary LLMNR queries. - - [RFC1536] Section 6 describes name error bugs and recommended - searchlist processing that will reduce unnecessary RCODE=3 - (authoritative name) errors, thereby also reducing unnecessary LLMNR - queries. - -3.1. LLMNR configuration - - Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is - possible for a dual stack host to be configured with the address of a - DNS server over IPv4, while remaining unconfigured with a DNS server - suitable for use over IPv6. - - In these situations, a dual stack host will send AAAA queries to the - configured DNS server over IPv4. However, an IPv6-only host - unconfigured with a DNS server suitable for use over IPv6 will be - unable to resolve names using DNS. Automatic IPv6 DNS configuration - mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely - deployed, and not all DNS servers support IPv6. Therefore lack of - IPv6 DNS configuration may be a common problem in the short term, and - LLMNR may prove useful in enabling linklocal name resolution over - IPv6. - - Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], - IPv6-only hosts may not be configured with a DNS server. Where there - is no DNS server authoritative for the name of a host or the - authoritative DNS server does not support dynamic client update over - IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not - be able to do DNS dynamic update, and other hosts will not be able to - resolve its name. - - For example, if the configured DNS server responds to AAAA RR queries - sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), - then it will not be possible to resolve the names of IPv6-only hosts. - In this situation, LLMNR over IPv6 can be used for local name - resolution. - - Similarly, if a DHCPv4 server is available providing DNS server - configuration, and DNS server(s) exist which are authoritative for - the A RRs of local hosts and support either dynamic client update - over IPv4 or DHCPv4-based dynamic update, then the names of local - - - -Esibov, Aboba & Thaler Standards Track [Page 15] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no - DNS server is authoritative for the names of local hosts, or the - authoritative DNS server(s) do not support dynamic update, then LLMNR - enables linklocal name resolution over IPv4. - - Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to - configure LLMNR on an interface. The LLMNR Enable Option, described - in [LLMNREnable], can be used to explicitly enable or disable use of - LLMNR on an interface. The LLMNR Enable Option does not determine - whether or in which order DNS itself is used for name resolution. - The order in which various name resolution mechanisms should be used - can be specified using the Name Service Search Option (NSSO) for DHCP - [RFC2937], using the LLMNR Enable Option code carried in the NSSO - data. - - It is possible that DNS configuration mechanisms will go in and out - of service. In these circumstances, it is possible for hosts within - an administrative domain to be inconsistent in their DNS - configuration. - - For example, where DHCP is used for configuring DNS servers, one or - more DHCP servers can fail. As a result, hosts configured prior to - the outage will be configured with a DNS server, while hosts - configured after the outage will not. Alternatively, it is possible - for the DNS configuration mechanism to continue functioning while - configured DNS servers fail. - - Unless unconfigured hosts periodically retry configuration, an outage - in the DNS configuration mechanism will result in hosts continuing to - use LLMNR even once the outage is repaired. Since LLMNR only enables - linklocal name resolution, this represents an unnecessary degradation - in capabilities. As a result, it is recommended that hosts without a - configured DNS server periodically attempt to obtain DNS - configuration. For example, where DHCP is used for DNS - configuration, [RFC2131] recommends a maximum retry interval of 64 - seconds. In the absence of other guidance, a default retry interval - of one (1) minute is RECOMMENDED. - -4. Conflict resolution - - The sender MUST anticipate receiving multiple replies to the same - LLMNR query, in the event that several LLMNR enabled computers - receive the query and respond with valid answers. When this occurs, - the responses may first be concatenated, and then treated in the same - manner that multiple RRs received from the same DNS server would; the - sender perceives no inherent conflict in the receipt of multiple - responses. - - - - -Esibov, Aboba & Thaler Standards Track [Page 16] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - There are some scenarios when multiple responders MAY respond to the - same query. There are other scenarios when only one responder MAY - respond to a query. Resource records for which the latter queries - are submitted are referred as UNIQUE throughout this document. The - uniqueness of a resource record depends on a nature of the name in - the query and type of the query. For example it is expected that: - - - multiple hosts may respond to a query for an SRV type record - - multiple hosts may respond to a query for an A or AAAA type - record for a cluster name (assigned to multiple hosts in - the cluster) - - only a single host may respond to a query for an A or AAAA - type record for a name. - - Every responder that responds to an LLMNR query AND includes a UNIQUE - record in the response: - - [1] MUST verify that there is no other host within the - scope of the LLMNR query propagation that can return - a resource record for the same name, type and class. - - [2] MUST NOT include a UNIQUE resource record in the - response without having verified its uniqueness. - - Where a host is configured to issue LLMNR queries on more than one - interface, each interface should have its own independent LLMNR - cache. For each UNIQUE resource record in a given interface's - configuration, the host MUST verify resource record uniqueness on - that interface. To accomplish this, the host MUST send an LLMNR - query for each UNIQUE resource record. - - By default, a host SHOULD be configured to behave as though all RRs - are UNIQUE. Uniqueness verification is carried out when the host: - - - starts up or is rebooted - - wakes from sleep (if the network interface was inactive during sleep) - - is configured to respond to the LLMNR queries on an interface - enabled for transmission and reception of IP traffic - - is configured to respond to the LLMNR queries using additional - UNIQUE resource records - - detects that an interface is connected and is usable - (e.g. an IEEE 802 hardware link-state change indicating - that a cable was attached or completion of authentication - (and if needed, association) with a wireless base station - or adhoc network - - When a host that has a UNIQUE record receives an LLMNR query for that - record, the host MUST respond. After the client receives a response, - - - -Esibov, Aboba & Thaler Standards Track [Page 17] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - it MUST check whether the response arrived on an interface different - from the one on which the query was sent. If the response arrives on - a different interface, the client can use the UNIQUE resource record - in response to LLMNR queries. If not, then it MUST NOT use the - UNIQUE resource record in response to LLMNR queries. - - The name conflict detection mechanism doesn't prevent name conflicts - when previously partitioned segments are connected by a bridge. In - order to minimize the chance of conflicts in such a situation, it is - recommended that steps be taken to ensure name uniqueness. For - example, the name could be chosen randomly from a large pool of - potential names, or the name could be assigned via a process designed - to guarantee uniqueness. - - When name conflicts are detected, they SHOULD be logged. To detect - duplicate use of a name, an administrator can use a name resolution - utility which employs LLMNR and lists both responses and responders. - This would allow an administrator to diagnose behavior and - potentially to intervene and reconfigure LLMNR responders who should - not be configured to respond to the same name. - -4.1. Considerations for Multiple Interfaces - - A multi-homed host may elect to configure LLMNR on only one of its - active interfaces. In many situations this will be adequate. - However, should a host need to configure LLMNR on more than one of - its active interfaces, there are some additional precautions it MUST - take. Implementers who are not planning to support LLMNR on multiple - interfaces simultaneously may skip this section. - - A multi-homed host checks the uniqueness of UNIQUE records as - described in Section 4. The situation is illustrated in figure 1. - - ---------- ---------- - | | | | - [A] [myhost] [myhost] - - Figure 1. Link-scope name conflict - - In this situation, the multi-homed myhost will probe for, and defend, - its host name on both interfaces. A conflict will be detected on one - interface, but not the other. The multi-homed myhost will not be - able to respond with a host RR for "myhost" on the interface on the - right (see Figure 1). The multi-homed host may, however, be - configured to use the "myhost" name on the interface on the left. - - Since names are only unique per-link, hosts on different links could - be using the same name. If an LLMNR client sends requests over - - - -Esibov, Aboba & Thaler Standards Track [Page 18] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - multiple interfaces, and receives replies from more than one, the - result returned to the client is defined by the implementation. The - situation is illustrated in figure 2. - - ---------- ---------- - | | | | - [A] [myhost] [A] - - - Figure 2. Off-segment name conflict - - If host myhost is configured to use LLMNR on both interfaces, it will - send LLMNR queries on both interfaces. When host myhost sends a - query for the host RR for name "A" it will receive a response from - hosts on both interfaces. - - Host myhost cannot distinguish between the situation shown in Figure - 2, and that shown in Figure 3 where no conflict exists. - - [A] - | | - ----- ----- - | | - [myhost] - - Figure 3. Multiple paths to same host - - This illustrates that the proposed name conflict resolution mechanism - does not support detection or resolution of conflicts between hosts - on different links. This problem can also occur with unicast DNS - when a multi-homed host is connected to two different networks with - separated name spaces. It is not the intent of this document to - address the issue of uniqueness of names within DNS. - -4.2. API issues - - [RFC2553] provides an API which can partially solve the name - ambiguity problem for applications written to use this API, since the - sockaddr_in6 structure exposes the scope within which each scoped - address exists, and this structure can be used for both IPv4 (using - v4-mapped IPv6 addresses) and IPv6 addresses. - - Following the example in Figure 2, an application on 'myhost' issues - the request getaddrinfo("A", ...) with ai_family=AF_INET6 and - ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both - interfaces and the resolver library will return a list containing - multiple addrinfo structures, each with an associated sockaddr_in6 - structure. This list will thus contain the IPv4 and IPv6 addresses - - - -Esibov, Aboba & Thaler Standards Track [Page 19] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - of both hosts responding to the name 'A'. Link-local addresses will - have a sin6_scope_id value that disambiguates which interface is used - to reach the address. Of course, to the application, Figures 2 and 3 - are still indistinguishable, but this API allows the application to - communicate successfully with any address in the list. - -5. Security Considerations - - LLMNR is by nature a peer-to-peer name resolution protocol. It is - therefore inherently more vulnerable than DNS, since existing DNS - security mechanisms are difficult to apply to LLMNR. While tools - exist to alllow an attacker to spoof a response to a DNS query, - spoofing a response to an LLMNR query is easier since the query is - sent to a link-scope multicast address, where every host on the - logical link will be made aware of it. - - In order to address the security vulnerabilities, the following - mechanisms are contemplated: - - [1] Scope restrictions. - [2] Usage restrictions. - [3] Cache and port separation. - [4] Authentication. - - These techniques are described in the following sections. - -5.1. Scope restriction - - With LLMNR it is possible that hosts will allocate conflicting names - for a period of time, or that attackers will attempt to deny service - to other hosts by allocating the same name. Such attacks also allow - hosts to receive packets destined for other hosts. - - Since LLMNR is typically deployed in situations where no trust model - can be assumed, it is likely that LLMNR queries and responses will be - unauthenticated. In the absence of authentication, LLMNR reduces the - exposure to such threats by utilizing UDP queries sent to a link- - scope multicast address, as well as setting the TTL (IPv4) or Hop - Limit (IPv6) fields to one (1) on TCP queries and responses. - - Using a TTL of one (1) to set up a TCP connection in order to send a - unicast LLMNR query reduces the likelihood of both denial of service - attacks and spoofed responses. Checking that an LLMNR query is sent - to a link-scope multicast address should prevent spoofing of - multicast queries by off-link attackers. - - While this limits the ability of off-link attackers to spoof LLMNR - queries and responses, it does not eliminate it. For example, it is - - - -Esibov, Aboba & Thaler Standards Track [Page 20] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - possible for an attacker to spoof a response to a frequent query - (such as an A or AAAA query for a popular Internet host), and by - using a TTL or Hop Limit field larger than one (1), for the forged - response to reach the LLMNR sender. - - When LLMNR queries are sent to a link-scope multicast address, it is - possible that some routers may not properly implement link-scope - multicast, or that link-scope multicast addresses may leak into the - multicast routing system. - - Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than - one in an LLMNR UDP response may enable denial of service attacks - across the Internet. However, since LLMNR responders only respond to - queries for which they are authoritative, and LLMNR does not provide - wildcard query support, it is believed that this threat is minimal. - - There also are scenarios such as public "hotspots" where attackers - can be present on the same link. These threats are most serious in - wireless networks such as 802.11, since attackers on a wired network - will require physical access to the home network, while wireless - attackers may reside outside the home. Link-layer security can be of - assistance against these threats if it is available. - -5.2. Usage restriction - - As noted in Sections 2 and 3, LLMNR is intended for usage in a - limited set of scenarios. - - If an LLMNR query is sent whenever a DNS server does not respond in a - timely way, then an attacker can poison the LLMNR cache by responding - to the query with incorrect information. To some extent, these - vulnerabilities exist today, since DNS response spoofing tools are - available that can allow an attacker to respond to a query more - quickly than a distant DNS server. - - Since LLMNR queries are sent and responded to on the local-link, an - attacker will need to respond more quickly to provide its own - response prior to arrival of the response from a legitimate - responder. If an LLMNR query is sent for an off-link host, spoofing a - response in a timely way is not difficult, since a legitimate - response will never be received. - - The vulnerability is more serious if LLMNR is given higher priority - than DNS among the enabled name resolution mechanisms. In such a - configuration, a denial of service attack on the DNS server would not - be necessary in order to poison the LLMNR cache, since LLMNR queries - would be sent even when the DNS server is available. In addition, the - LLMNR cache, once poisoned, would take precedence over the DNS cache, - - - -Esibov, Aboba & Thaler Standards Track [Page 21] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - - eliminating the benefits of cache separation. As a result, LLMNR is - only used as a name resolution mechanism of last resort. - -5.3. Cache and port separation - - In order to prevent responses to LLMNR queries from polluting the DNS - cache, LLMNR implementations MUST use a distinct, isolated cache for - LLMNR on each interface. The use of separate caches is most effective - when LLMNR is used as a name resolution mechanism of last resort, - since this minimizes the opportunities for poisoning the LLMNR cache, - and decreases reliance on it. - - LLMNR operates on a separate port from DNS, reducing the likelihood - that a DNS server will unintentionally respond to an LLMNR query. - -5.4. Authentication - - LLMNR implementations may not support DNSSEC or TSIG, and as a - result, responses to LLMNR queries may be unauthenticated. If - authentication is desired, and a pre-arranged security configuration - is possible, then IPsec ESP with a null-transform MAY be used to - authenticate LLMNR responses. In a small network without a - certificate authority, this can be most easily accomplished through - configuration of a group pre-shared key for trusted hosts. - -6. IANA Considerations - - This specification creates one new name space: the reserved bits in - the LLMNR header. These are allocated by IETF Consensus, in - accordance with BCP 26 [RFC2434]. - - LLMNR requires allocation of port 5355 for both TCP and UDP. - - LLMNR requires allocation of link-scope multicast IPv4 address - 224.0.0.252, as well as link-scope multicast IPv6 address - FF02:0:0:0:0:0:1:3. - -7. References - -7.1. Normative References - -[RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", RFC 1035, November 1987. - -[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 22] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - -[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", - RFC 2308, March 1998. - -[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC - 2365, July 1998. - -[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. - -[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - -[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 - (IPv6) Specification", RFC 2460, December 1998. - -[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - -[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission - Timer", RFC 2988, November 2000. - -7.2. Informative References - -[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested - Fixes", RFC 1536, October 1993. - -[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, - March 1997. - -[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - -[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - -[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic - Socket Interface Extensions for IPv6", RFC 2553, March 1999. - - - -Esibov, Aboba & Thaler Standards Track [Page 23] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC - 2937, September 2000. - -[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for - IPv6 (DHCPv6)", RFC 3315, July 2003. - -[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of - Caching", IEEE/ACM Transactions on Networking, Volume 10, - Number 5, pp. 589, October 2002. - -[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local - unicast addresses to communicate with recursive DNS servers", - Internet draft (work in progress), draft-ietf-ipv6-dns- - discovery-07.txt, October 2002. - -[IPV4Link] - Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration - of IPv4 Link-Local Addresses", Internet draft (work in - progress), draft-ietf-zeroconf-ipv4-linklocal-15.txt, May - 2004. - -[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- - Portable Operating System Interface (POSIX). Open Group - Technical Standard: Base Specifications, Issue 6, December - 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin - -[LLMNREnable] - Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work - in progress), draft-guttman-mdns-enable-02.txt, April 2002. - -[NodeInfo] - Crawford, M., "IPv6 Node Information Queries", Internet draft - (work in progress), draft-ietf-ipn-gwg-icmp-name- - lookups-09.txt, May 2002. - -Acknowledgments - - This work builds upon original work done on multicast DNS by Bill - Manning and Bill Woodcock. Bill Manning's work was funded under DARPA - grant #F30602-99-1-0523. The authors gratefully acknowledge their - contribution to the current specification. Constructive input has - also been received from Mark Andrews, Stuart Cheshire, Randy Bush, - Robert Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik - Guttman, Myron Hattig, Thomas Narten, Christian Huitema, Erik - Nordmark, Sander Van-Valkenburg, Tomohide Nagashima, Brian Zill, - Keith Moore and Markku Savela. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 24] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -Authors' Addresses - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - Bernard Aboba - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 706 6605 - EMail: bernarda@microsoft.com - - Dave Thaler - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - Phone: +1 425 703 8835 - EMail: dthaler@microsoft.com - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - -Esibov, Aboba & Thaler Standards Track [Page 25] - - - - - -INTERNET-DRAFT LLMNR 18 July 2004 - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - -Open Issues - - Open issues with this specification are tracked on the following web - site: - - http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Esibov, Aboba & Thaler Standards Track [Page 26] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt deleted file mode 100644 index c5c3b84ba3d55..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-04.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -DNSEXT Working Group Yuji Kamite -INTERNET-DRAFT NTT Communications -<draft-ietf-dnsext-tkey-renewal-mode-04.txt> Masaya Nakayama -Expires: Aug. 2004 The University of Tokyo - Feb. 2004 - - - - - TKEY Secret Key Renewal Mode - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with all - provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering Task - Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - This document defines a new mode in TKEY and proposes an atomic - method for changing secret keys used for TSIG periodically. - Originally, TKEY provides methods of setting up shared secrets other - than manual exchange, but it cannot control timing of key renewal - very well though it can add or delete shared keys separately. This - proposal is a systematical key renewal procedure intended for - preventing signing DNS messages with old and non-safe keys - permanently. - - - - - - - - -Kamite, et. al. [Page 1] - -INTERNET-DRAFT Feb. 2004 - - - Table of Contents - - -1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4 - 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4 -2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 7 - 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . . . 7 - 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . . 7 - 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . . . 8 - 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . . . 8 - 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 10 - 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10 - 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 - 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11 - 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12 - 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13 - 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14 -3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 15 -4 Compulsory Key Revocation . . . . . . . . . . . . . . . . . . . . 15 - 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . . . 15 - 4.2 Authentication Methods Considerations . . . . . . . . . . . . 15 -5 Special Considerations for Two Servers' Case . . . . . . . . . . 16 - 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16 -6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17 -7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17 -8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 20 -9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20 -10 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . 21 -11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 -Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22 - - - - - - - - - - - - - - - -Kamite, et. al. [Page 2] - -INTERNET-DRAFT Feb. 2004 - - -1. Introduction - - TSIG [RFC2845] provides DNS message integrity and the - request/transaction authentication by means of message authentication - codes (MAC). TSIG is a practical solution in view of calculation - speed and availability. However, TSIG does not have exchanging - mechanism of shared secret keys between server and resolver, and - administrators might have to exchange secret keys manually. TKEY - [RFC2930] is introduced to solve such problem and it can exchange - secrets for TSIG via networks. - - In various modes of TKEY, a server and a resolver can add or delete a - secret key be means of TKEY message exchange. However, the existing - TKEY does not care fully about the management of keys which became - too old, or dangerous after long time usage. - - It is ideal that the number of secret which a pair of hosts share - should be limited only one, because having too many keys for the same - purpose might not only be a burden to resolvers for managing and - distinguishing according to servers to query, but also does not seem - to be safe in terms of storage and protection against attackers. - Moreover, perhaps holding old keys long time might give attackers - chances to compromise by scrupulous calculation. - - Therefore, when a new shared secret is established by TKEY, the - previous old secret should be revoked immediately. To accomplish - this, DNS servers must support a protocol for key renewal. This - document specifies procedure to refresh secret keys between two hosts - which is defined within the framework of TKEY, and it is called "TKEY - Secret Key Renewal Mode". - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and - "OPTIONAL" in this document are to be interpreted as described in - [RFC2119]. - - -1.1. Defined Words - - * Inception Time: Beginning of the shared secret key lifetime. This - value is determined when the key is generated. - - * Expiry Limit: Time limit of the key's validity. This value is - determined when a new key is generated. After Expiry Limit, server - and client (resolver) must not authenticate TSIG signed with the key. - Therefore, Renewal to the next key should be carried out before - Expiry Limit. - - * Partial Revocation Time: Time when server judges the key is too old - - - -Kamite, et. al. [Page 3] - -INTERNET-DRAFT Feb. 2004 - - - and must be updated. It must be between Inception Time and Expiry - Limit. This value is determined by server freely following its - security policy. e.g., If the time from Inception to Partial - Revocation is short, renewal will be carried out more often, which - might be safer. - - * Revocation Time: Time when the key becomes invalid and can be - removed. This value is not determined in advance because it is the - actual time when revocation is completed. - - * Adoption Time: Time when the new key is adopted as the next key - formally. After Adoption, the key is valid and server and client can - generate or verify TSIG making use of it. Adoption Time also means - the time when it becomes possible to remove the previous key, so - Revocation and Adoption are usually done at the same time. - - - Partial - Inception Revocation Revocation Expiry Limit - | | | | - |----------------|- - - - - - >>|- (revoked) -| - | | | | - previous key | | | - |- - - -|-------------------->> time - | | new key - Inception Adoption - - -1.2. New Format and Assigned Numbers - - TSIG - ERROR = (PartialRevoke), TBD - - TKEY - Mode = (server assignment for key renewal), TBD - Mode = (Diffie-Hellman exchange for key renewal), TBD - Mode = (resolver assignment for key renewal), TBD - Mode = (key adoption), TBD - - -1.3. Overview of Secret Key Renewal Mode - - When a server receives a query from a client signed with a TSIG key, - It always checks if the present time is within the range of usage - duration it considers safe. If it is judged that the key is too old, - i.e., after Partial Revocation Time, the server comes to be in - Partial Revocation state about the key, and this key is called - partially revoked. - - - -Kamite, et. al. [Page 4] - -INTERNET-DRAFT Feb. 2004 - - - In this state, if a client sends a normal query (e.g., question about - A RR) other than TKEY Renewal request with TSIG signed with the old - key, the server returns an error message to notify that the time to - renew has come. This is called "PartialRevoke" error message. It is - server's choice whether it returns PartialRevoke or not. If and only - if the server is ready for changing its own key, it decides to return - PartialRevoke. - - The client which got this error is able to notice that it is - necessary to refresh the secret. To make a new shared secret, it - sends a TKEY Renewal request, in which several keying methods are - available. It can make use of TSIG authentication signed with the - partially revoked key mentioned above. - - After new secret establishment, the client sends a TKEY Adoption - request for renewal confirmation. This can also be authenticated with - the partially revoked key. If this is admitted by the server, the new - key is formally adopted, and at the same time the corresponding old - secret is invalidated. Then the client can send the first query again - signed with the new key. - - Key renewal procedure is executed based on two-phase commit - mechanism. The first phase is the TKEY Renewal request and its - response, which means preparatory confirmation for key update. The - second phase is Adoption request and its response. If the server gets - request and client receives the response successfully, they can - finish renewal process. If any error happens and renewal process - fails during these phases, client should roll back to the beginning - of the first phase, and send TKEY Renewal request again. This - rollback can be done until the Expiry Limit of the key. - - -2. Shared Secret Key Renewal - - Suppose a server and a client agree to change their TSIG keys - periodically. Key renewal procedure is defined between two hosts. - -2.1. Key Usage Time Check - - Whenever a server receives a query with TSIG and can find a key that - is used for signing it, the server checks its Inception Time, Partial - Revocation Time and Expiry Limit (this information is usually - memorized by the server). - - When the present time is before Inception Time, the server MUST NOT - verify TSIG with the key, and server acts the same way as when the - key used by the client is not recognized. It follows [RFC2845] 4.5.1. - - - - -Kamite, et. al. [Page 5] - -INTERNET-DRAFT Feb. 2004 - - - When the present time is equal to Inception Time, or between - Inception Time and Partial Revocation Time, the behavior of the - server is the same as when a valid key is found. It follows [RFC2845] - 4.5.2 and 4.5.3. - - When the present time is the same as the Partial Revocation Time, or - between the Partial Revocation Time and Expiry Limit, the server - comes to be in Partial Revocation state about the TSIG key and - behaves according to the next section. - - When the present time is the same as the Expiry Time or after it, the - server MUST NOT verify TSIG with the key, and returns error messages - in the same way as when the key used by the client is not recognized. - It follows [RFC2845] 4.5.1. - - -2.2. Partial Revocation - - In Partial Revocation state, we say the server has partially revoked - the key and the key has become a "partially revoked key". - - If server has received a query signed with the partially revoked key - for TKEY Renewal request (See section 2.3.) or Key Adoption request - (See section 2.4.), then server does proper process following each - specification. If it is for TKEY key deletion request ([RFC2930] - 4.2), server MAY process usual deletion operation defined therein. - - If server receives other types of query signed with the partially - revoked key, and both the corresponding MAC and signed TIME are - verified, then server begins returning answer whose TSIG error code - is "PartialRevoke" (See section 9.). Server MUST randomly but with - increasing frequency return PartialRevoke when in the Partial - Revocation state. - - Server can decide when it actually sends PartialRevoke, checking if - it is appropriate time for renewal. Server MUST NOT return - PartialRevoke if this is apart long lived TSIG transaction (such as - AXFR) that started before the Partial Revocation Time. - - If the client receives PartialRevoke and understands it, then it MUST - retry the query with the old key unless a new key has been adopted. - Client SHOULD start the process to renew the TSIG key. For key - renewal procedure, see details in Section 2.3 and 2.4. - - PartialRevoke period (i.e., time while server returns PartialRevoke - randomely) SHOULD be small, say 2-5% of key lifetime. This is - server's choice. - - - - -Kamite, et. al. [Page 6] - -INTERNET-DRAFT Feb. 2004 - - - Server MUST keep track of clients ignoring PartialRevoke, thus - indicating ignorance of this TKEY mode. - - PartialRevoke error messages have the role to inform clients of the - keys' partial revocation and urge them to send TKEY Renewal requests. - These error responses MUST be signed with those partial revoked keys - if the queries are signed with them. They are sent only when the - signing keys are found to be partially revoked. If the MAC of TSIG - cannot be verified with the partially revoked keys, servers MUST NOT - return PartialRevoke error with MAC, but MUST return another error - such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other - words, a server informs its key's partial revocation only when the - MAC in the received query is valid. - - -2.3. Key Renewal Message Exchange - -2.3.1. Query for Key Renewal - - If a client has received a PartialRevoke error and authenticated the - response based on TSIG MAC, it sends a TKEY query for Key Renewal (in - this document, we call it Renewal request, too.) to the server. The - request MUST be signed with TSIG or SIG(0) [RFC2931] for - authentication. If TSIG is selected, the client can sign it with the - partial revoked key. - - Key Renewal can use one of several keying methods which is indicated - in "Mode" field of TKEY RR, and its message structure is dependent on - that method. - - -2.3.2. Response for Key Renewal - - The server which has received Key Renewal request first tries to - verify TSIG or SIG(0) accompanying it. If the TSIG is signed and - verified with the partially revoked key, the request MUST be - authenticated. - - After authentication, server must check existing old key's validity. - If the partially revoked key indicated in the request TKEY's OldName - and OldAlgorithm field (See section 2.3.4.) does not exist at the - server, "BADKEY" [RFC2845] is given in Error field for response. If - any other error happens, server returns appropriate error messages - following the specification described in section 2.5. If there are no - errors, server returns a Key Renewal answer. This answer MUST be - signed with TSIG or SIG(0) for authentication. - - When this answer is successfully returned and no error is detected by - - - -Kamite, et. al. [Page 7] - -INTERNET-DRAFT Feb. 2004 - - - client, a new shared secret can be established. The details of - concrete keying procedure are given in the section 2.5. - - Note: - Sometimes Adoption message and new Renewal request will cross on - the wire. In this case the newly generated key Adoption message is - resent. - - -2.3.3. Attributes of Generated Key - - As a result of this message exchange, client comes to know the newly - generated key's attributes such as key's name, Inception Time and - Expiry Limit. They are decided by the server and told to the client; - in particular, however, once the server has decided Expiry Limit and - returned a response, it should obey the decision as far as it can. In - other words, they SHOULD NOT change time values for checking Expiry - Limit in the future without any special reason, such as security - issue like "Emergency Compulsory Revocation" described in section 8. - - On the other hand, Partial Revocation Time of this generated key is - not decided based on the request, and not informed to the client. The - server can determine any value as long as it is between Inception - Time and Expiry Limit. However, the period from Inception to Partial - Revocation SHOULD be fixed as the server side's configuration or be - set the same as the corresponding old key's one. - - Note: - Even if client sends Key Renewal request though the key described - in OldName has not been partially revoked yet, server does renewal - processes. At the moment when the server accepts such requests - with valid authentication, it MUST forcibly consider the key is - already partially revoked, that is, the key's Partial Revocation - Time must be changed into the present time (i.e., the time when - the server receives the request). - - -2.3.4. TKEY RR structure - - TKEY RR for Key Renewal message has the structure given below. In - principle, format and definition for each field follows [RFC2930]. - Note that each keying scheme sometimes needs different interpretation - of RDATA field; for detail, see section 2.5. - - Field Type Comment - ------- ------ ------- - NAME domain used for a new key, see below - TYPE u_int16_t (defined in [RFC2930]) - - - -Kamite, et. al. [Page 8] - -INTERNET-DRAFT Feb. 2004 - - - CLASS u_int16_t (defined in [RFC2930]) - TTL u_int32_t (defined in [RFC2930]) - RDLEN u_int16_t (defined in [RFC2930]) - RDATA: - Algorithm: domain algorithm for a new key - Inception: u_int32_t about the keying material - Expiration: u_int32_t about the keying material - Mode: u_int16_t scheme for key agreement - see section 9. - Error: u_int16_t see description below - Key Size: u_int16_t see description below - Key Data: octet-stream - Other Size: u_int16_t (defined in [RFC2930]) - size of other data - Other Data: newly defined: see description below - - - For "NAME" field, both non-root and root name are allowed. It may - be used for a new key's name in the same manner as [RFC2930] 2.1. - - "Algorithm" specifies which algorithm is used for agreed keying - material, which is used for identification of the next key. - - "Inception" and "Expiration" are used for the valid period of - keying material. The meanings differ somewhat according to whether - the message is request or answer, and its keying scheme. - - "Key Data" has different meanings according to keying schemes. - - "Mode" field stores the value in accordance with the keying method, - and see section 2.5. Servers and clients supporting TKEY Renewal - method MUST implement "Diffie-Hellman exchange for key renewal" - scheme. All other modes are OPTIONAL. - - "Error" is an extended RCODE which includes "PartialRevoke" value - too. See section 9. - - "Other Data" field has the structure given below. They describe - attributes of the key to be renewed. - - in Other Data filed: - - Field Type Comment - ------- ------ ------- - OldNAME domain name of the old key - OldAlgorithm domain algorithm of the old key - - - - - -Kamite, et. al. [Page 9] - -INTERNET-DRAFT Feb. 2004 - - - "OldName" indicates the name of the previous key (usually, - this is partially revoked key's name that client noticed by - PartialRevoke answer from server), and "OldAlogirthm" - indicates its algorithm. - - -2.4. Key Adoption - -2.4.1. Query for Key Adoption - - After receiving a TKEY Renewal answer, the client gets the same - secret as the server. Then, it sends a TKEY Adoption request. The - request's question section's QNAME field is the same as the NAME - filed of TKEY written below. In additional section, there is one TKEY - RR that has the structure and values described below. - - "NAME" field is the new key's name to be adopted which was already - generated by Renewal message exchange. "Algorithm" is its - algorithm. "Inception" means the key's Inception Time, and - "Expiration" means Expiry Limit. - - "Mode" field is the value of "key adoption". See section 9. - - "Other Data" field in Adoption has the same structure as that of - Renewal request message. "OldName" means the previous old key, and - "OldAlogirthm" means its algorithm. - - Key Adoption request MUST be signed with TSIG or SIG(0) for - authentication. The client can sign TSIG with the previous key. Note - that until Adoption is finished, the new key is treated as invalid, - thus it cannot be used for authentication immediately. - - -2.4.2. Response for Key Adoption - - The server which has received Adoption request, it verifies TSIG or - SIG(0) accompanying it. If the TSIG is signed with the partially - revoked key and can be verified, the message MUST be authenticated. - - If the next new key indicated by the request TKEY's "NAME" is not - present at the server, BADNAME [RFC2845] is given in Error field and - the error message is returned. - - If the next key exists but it has not been adopted formally yet, the - server confirms the previous key's existence indicated by the - "OldName" and "OldAlgorithm" field. If it succeeds, the server - executes Adoption of the next key and Revocation of the previous key. - Response message duplicates the request's TKEY RR with NOERROR, - - - -Kamite, et. al. [Page 10] - -INTERNET-DRAFT Feb. 2004 - - - including "OldName" and "OldAlgorithm" that indicate the revoked key. - - If the next key exists but it is already adopted, the server returns - a response message regardless of the substance of the request TKEY's - "OldName". In this response, Response TKEY RR has the same data as - the request's one except as to its "Other Data" that is changed into - null (i.e., "Other Size" is zero), which is intended for telling the - client that the previous key name was ignored, and the new key is - already available. - - Client sometimes has to retry Adoption request. Suppose the client - sent request signed with the partially revoked key, but its response - did not return successfully (e.g., due to the drop of UDP packet). - Client will probably retry Adoption request; however, the request - will be refused in the form of TSIG "BADKEY" error because the - previous key was already revoked. In this case, client will - retransmit Adoption request signed with the next key, and expect a - response which has null "Other Data" for confirming the completion of - renewal. - - -2.5. Keying Schemes - - In Renewal message exchanges, there are no limitations as to which - keying method is actually used. The specification of keying - algorithms is independent of the general procedure of Renewal that is - described in section 2.3. - - Now this document specifies three algorithms in this section, but - other future documents can make extensions defining other methods. - - -2.5.1. DH Exchange for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.1. This - specification only describes the difference from it and special - notice; assume that all other points, such as keying material - computation, are the exactly same as the specification of [RFC2930] - 4.1. - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - the client's Diffie-Hellman public key [RFC2539]. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - - - -Kamite, et. al. [Page 11] - -INTERNET-DRAFT Feb. 2004 - - - TKEY "Mode" field stores the value of "DH exchange for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is used as a random, following [RFC2930] 4.1. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. If - any incompatible DH key is found in the request, "BADKEY" - [RFC2845] is given in Error field for response. "FORMERR" is given - if the query included no DH KEY. - - If there are no errors, the server processes a response according - to Diffie-Hellman algorithm and returns the answer. In this - answer, there is one TKEY RR in answer section and KEY RR(s) in - additional section. - - As long as no error has occurred, all values of TKEY are equal to - that of the request message except TKEY NAME, TKEY RDLEN, RDATA's - Inception, Expiration, Key Size and Key Data. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is used as an additional nonce, following - [RFC2930] 4.1. - - The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in - the additional section and a server Diffie-Hellman KEY RR will - also be present in the answer section, following [RFC2930] 4.1. - - -2.5.2. Server Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.4. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.4. - - - -Kamite, et. al. [Page 12] - -INTERNET-DRAFT Feb. 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. KEY RR is - used in encrypting the response. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "server assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is provided following the specification of - [RFC2930] 4.4. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the query specified no encryption key. - - If there are no errors, the server response contains one TKEY RR - in the answer section, and echoes the KEY RR provided in the query - in the additional information section. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - TKEY "Key Data" is the assigned keying data encrypted under the - public key in the resolver provided KEY RR, which is the same as - [RFC2930] 4.4. - - -2.5.3. Resolver Assigned Keying for Key Renewal - - This scheme is defined as an extended method of [RFC2930] 4.5. This - specification only describes the difference from it and special - notice; assume that all other points, such as secret encrypting - method, are the exactly same as the specification of [RFC2930] 4.5. - - - - -Kamite, et. al. [Page 13] - -INTERNET-DRAFT Feb. 2004 - - - Query - In Renewal request for type TKEY with this mode, there is one TKEY - RR and one KEY RR in the additional information section. TKEY RR - has the encrypted keying material and KEY RR is the server public - key used to encrypt the data. - - QNAME in question section is the same as that of "NAME" field in - TKEY RR, i.e., it means the requested new key's name. - - TKEY "Mode" field stores the value of "resolver assignment for key - renewal". See section 9. - - TKEY "Inception" and "Expiration" are those requested for the - keying material, that is, requested usage period of a new key. - - TKEY "Key Data" is the encrypted keying material. - - Response - The server which received this request first verifies the TSIG, - SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the - old key's existence validity is checked, following section 2.3. - "FORMERR" is given if the server does not have the corresponding - private key for the KEY RR that was shown sin the request. - - If there are no errors, the server returns a response. The - response contains a TKEY RR in the answer section to tell the - shared key's name and its usage time values. - - TKEY "NAME" field in the answer specifies the name of newly - produced key which the client MUST use. - - TKEY "Inception" and "Expiration" mean the periods of the produced - key usage. "Inception" is set to be the time when the new key is - actually generated or the time before it, and it will be regarded - as Inception Time. "Expiration" is determined by the server, and - it will be regarded as Expiry Limit. - - -2.6. Considerations about Non-compliant Hosts - - Key Renewal requests and responses must be exchanged between hosts - which can understand them and do proper processes. PartialRevoke - error messages will be only ignored if they should be returned to - non-compliant hosts. - - Note that server does not inform actively the necessity of renewal to - clients, but inform it as responses invoked by client's query. - Server needs not care whether the PartialRevoke errors has reached - - - -Kamite, et. al. [Page 14] - -INTERNET-DRAFT Feb. 2004 - - - client or not. If client has not received yet because of any reasons - such as packet drops, it will resend the queries, and finally will be - able to get PartialRevoke information. - - -3. Secret Storage - - Every server keeps all secrets and attached information, e.g., - Inception Time, Expiry Limit, etc. safely to be able to recover from - unexpected stop. To accomplish this, formally adopted keys SHOULD be - memorized not only on memory, but also be stored in the form of some - files. It will become more secure if they are stored in ecrypted - form. - - -4. Compulsory Key Revocation - -4.1. Compulsory Key Revocation by Server - - There is a rare but possible case that although servers have already - partially revoked keys, clients do not try to send any Renewal - requests. If this state continues, in the future it will become the - time of Expiry Limit. After Expiry Limit, the keys will be expired - and completely removed, so this is called Compulsory Key Revocation - by server. - - If Expiry Limit is too distant from the Partial Revocation Time, then - even though very long time passes, clients will be able to refresh - secrets only if they add TSIG signed with those old partially revoked - keys into requests, which is not safe. - - On the other hand, if Expiry Limit is too close to Partial Revocation - Time, perhaps clients might not be able to notice their keys' Partial - Revocation by getting "PartialRevoke" errors. - - Therefore, servers should set proper Expiry Limit to their keys, - considering both their keys' safety, and enough time for clients to - send requests and process renewal. - - -4.2. Authentication Methods Considerations - - It might be ideal to provide both SIG(0) and TSIG as authentication - methods. For example: - - A client and a server start SIG(0) authentication at first, to - establish TSIG shared keys by means of "Query for Diffie-Hellman - Exchanged Keying" as described in [RFC2930] 4.1. Once they get - - - -Kamite, et. al. [Page 15] - -INTERNET-DRAFT Feb. 2004 - - - shared secret, they keep using TSIG for queries and responses. - After a while the server returns a "ParitalRevoke" error and they - begin a key renewal process. Both TSIG signed with partially - revoked keys and SIG(0) are okay for authentication, but TSIG would - be easier to use considering calculation efficiency. - - Suppose now client is halted for long time with some reason. - Because server does not execute any renewal process, it will - finally do Compulsory Revocation. Even if client restarts and sends - a key Renewal request, it will fail because old key is already - deleted at server. - - At this moment, however, if client also uses SIG(0) as another - authentication method, it can make a new shared key again and - recover successfully by sending "Query for Diffie-Hellman Exchanged - Keying" with SIG(0). - - -5. Special Considerations for Two servers' Case - - This section refers to the case where both hosts are DNS servers - which can act as full resolvers as well and using one shared key - only. If one server (called Server A) wants to refresh a shared key - (called "Key A-B"), it will await a TKEY Renewal request from the - other server (called Server B). However, perhaps Server A wants to - refresh the key right now. - - In this case, Server A is allowed to send a Renewal request to Server - B, if Server A knows the Key A-B is too old and wants to renew it - immediately. - - Note that the initiative in key renewal belongs to Server A because - it can notice the Partial Revocation Time and decide key renewal. If - Server B has information about Partial Revocation Time as well, it - can also decide for itself to send Renewal request to Server A. - However, it is not essential for both two servers have information - about key renewal timing. - -5.1. To Cope with Collisions of Renewal Requests - - At least one of two hosts which use Key Renewal must know their key - renewal information such as Partial Revocation Time. It is okay that - both hosts have it. - - Provided that both two servers know key renewal timing information, - there is possibility for them to begin partial revocation and sending - Renewal requests to each other at the same time. Such collisions will - not happen so often because Renewal requests are usually invoked when - - - -Kamite, et. al. [Page 16] - -INTERNET-DRAFT Feb. 2004 - - - hosts want to send queries, but it is possible. - - When one of two servers tries to send Renewal requests, it MUST - protect old secrets that it has partially revoked and prevent it from - being refreshed by any requests from the other server (i.e., it must - lock the old secret during the process of renewal). While the server - is sending Renewal requests and waiting responses, it ignores the - other server's Renewal requests. - - Therefore, servers might fail to change secrets by means of their own - requests to others. After failure they will try to resend, but they - should wait for random delays by the next retries. If they get any - Renewal requests from others while they are waiting, their shared - keys may be refreshed, then they do not need to send any Renewal - requests now for themselves. - - -6. Key Name Considerations - - Since both servers and clients have only to distinguish new secrets - and old ones, keys' names do not need to be specified strictly. - However, it is recommended that some serial number or key generation - time be added to the name and that the names of keys between the same - pair of hosts should have some common labels among their keys. For - example, suppose A.example.com. and B.example.com. share the key - "<serial number>.A.example.com.B.example.com." such as - "10010.A.example.com.B.example.com.". After key renewal, they change - their secret and name into "10011.A.example.com.B.example.com." - - Servers and clients must be able to use keys properly for each query. - Because TSIG secret keys themselves do not have any particular IDs to - be distinguished and would be identified by their names and - algorithm, it must be understood correctly what keys are refreshed. - - -7. Example Usage of Secret Key Renewal Mode - - This is an example of Renewal mode usage where a Server, - server.example.com, and a Client, client.exmple.com have an initial - shared secret key named "00.client.example.com.server.example.com". - - (1) The time values for key - "00.client.example.com.server.example.com" was set as follows: - Inception Time is at 1:00, Expiry Limit is at 21:00. - - (2) At Server, renewal time has been set: Partial Revocation Time - is at 20:00. - - - - -Kamite, et. al. [Page 17] - -INTERNET-DRAFT Feb. 2004 - - - (3) Suppose the present time is 19:55. If Client sends a query - signed with key "00.client.example.com.server.example.com" to ask - the IP address of "www.example.com", finally it will get a proper - answer from Server with valid TSIG (NOERROR). - - (4) At 20:05. Client sends a query to ask the IP address of - "www2.example.com". It is signed with key - "00.client.example.com.server.example.com". Server returns an - answer for the IP address. However, server has begun retuning - PartialRevoke Error randomely. This answer includes valid TSIG MAC - signed with "00.client.example.com.server.example.com", and its - Error Code indicates PartialRevoke. Client understands that the - current key is partially revoked. - - (5) At 20:06. Client sends a Renewal request to Server. This - request is signed with key - "00.client.example.com.server.example.com". It includes data such - as: - - Question Section: - QNAME = 01.client.example.com. (Client can set this freely) - TYPE = TKEY - - Additional Section: - 01.client.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a KEY RR for DH and a TSIG RR. - - (6) As soon as Server receives this request, it verifies TSIG. It - is signed with the partially revoked key - "00.client.example.com.server.example.com". and Server accepts the - request. It creates a new key by Diffie-Hellman calculation and - returns an answer which includes data such as: - - Answer Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (DH exchange for key renewal) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - - -Kamite, et. al. [Page 18] - -INTERNET-DRAFT Feb. 2004 - - - Answer Section also contains KEY RRs for DH. - - Additional Section also contains a TSIG RR. - This response is signed with key - "00.client.example.com.server.example.com" without error. - - At the same time, Server decides to set the Partial Revocation Time - of this new key "01.client.example.com.server.example.com." as next - day's 15:00. - - (7) Client gets the response and checks TSIG MAC, and calculates - Diffie-Hellman. It will get a new key, and it has been named - "01.client.example.com.server.example.com" by Server. - - (8) At 20:07. Client sends an Adoption request to Server. This - request is signed with the previous key - "00.client.example.com.server.example.com". It includes: - - Question Section: - QNAME = 01.client.example.com.server.example.com. - TYPE = TKEY - - Additional Section: - 01.client.example.com.server.example.com. TKEY - Algorithm = hmac-md5-sig-alg.reg.int. - Inception = (value meaning 20:00) - Expiration = (value meaning next day's 16:00) - Mode = (key adoption) - OldName = 00.client.example.com.server.example.com. - OldAlgorithm = hmac-md5-sig-alg.reg.int. - - Additional Section also contains a TSIG RR. - - (9) Server verifies the query's TSIG. It is signed with the - previous key and authenticated. It returns a response whose TKEY RR - is the same as the request's one. The response is signed with key - "00.client.example.com.server.example.com.". As soon as the - response is sent, Server revokes and removes the previous key. At - the same time, key "01.client.example.com.server.example.com." is - validated. - - (10) Client acknowledges the success of Adoption by receiving the - response. Then, it retries to send an original question about - "www2.example.com". It is signed with the adopted key - "01.client.example.com.server.example.com", so Server authenticates - it and returns an answer. - - - - - -Kamite, et. al. [Page 19] - -INTERNET-DRAFT Feb. 2004 - - - (11) This key is used until next day's 15:00. After that, it will - be partially revoked again. - - -8. Security Considerations - - This document considers about how to refresh shared secret. Secret - changed by this method is used at servers in support of TSIG - [RFC2845]. - - [RFC2104] says that current attacks to HMAC do not indicate a - specific recommended frequency for key changes but periodic key - refreshment is a fundamental security practice that helps against - potential weaknesses of the function and keys, and limits the damage - of an exposed key. TKEY Secret Key Renewal provides the method of - periodical key refreshment. - - In TKEY Secret Key Renewal, clients need to send two requests - (Renewal and Adoption) and spend time to finish their key renewal - processes. Thus the usage period of secrets should be considered - carefully based on both TKEY processing performance and security. - - This document specifies the procedure of periodical key renewal, but - actually there is possibility for servers to have no choice other - than revoking their secret keys immediately especially when the keys - are found to be compromised by attackers. This is called "Emergency - Compulsory Revocation". For example, suppose the original Expiry - Limit was set at 21:00, Partial Revocation Time at 20:00 and - Inception Time at 1:00. if at 11:00 the key is found to be - compromised, the server sets Expiry Limit forcibly to be 11:00 or - before it. - - Consequently, once Compulsory Revocation (See section 4.) is carried - out, normal renewal process described in this document cannot be done - any more as far as the key is concerned. However, after such - accidents happened, the two hosts are able to establish secret keys - and begin renewal procedure only if they have other (non-compromised) - shared TSIG keys or safe SIG(0) keys for the authentication of - initial secret establishment such as Diffie-Hellman Exchanged Keying. - - -9. IANA Considerations - - IANA needs to allocate a value for "DH exchange for key renewal", - "server assignment for key renewal", "resolver assignment for key - renewal" and "key adoption" in the mode filed of TKEY. It also needs - to allocate a value for "PartialRevoke" from the extended RCODE - space. - - - -Kamite, et. al. [Page 20] - -INTERNET-DRAFT Feb. 2004 - - -10. Acknowledgement - - The authors would like to thank Olafur Gudmundsson, whose helpful - input and comments contributed greatly to this document. - - -11. References - -[RFC2104] - H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message - Authentication", RFC2104, February 1997. - -[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - -[RFC2539] - D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name - System (DNS)", RFC 2539, March 1999. - -[RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, - May 2000. - -[RFC2930] - D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'', - RFC 2930, September 2000. - -[RFC2931] - D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s - )", RFC 2931, September 2000. - - - - - - - - - - - - - - - - - - - -Kamite, et. al. [Page 21] - -INTERNET-DRAFT Feb. 2004 - - -Authors' Addresses - - Yuji Kamite - NTT Communications Corporation - Tokyo Opera City Tower - 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo - 163-1421, Japan - EMail: y.kamite@ntt.com - - - Masaya Nakayama - Information Technology Center, The University of Tokyo - 2-11-16 Yayoi, Bunkyo-ku, Tokyo - 113-8658, Japan - EMail: nakayama@nc.u-tokyo.ac.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kamite, et. al. [Page 22] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt deleted file mode 100644 index 1133b0c87d49e..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-00.txt +++ /dev/null @@ -1,466 +0,0 @@ - - -INTERNET-DRAFT Donald E. Eastlake 3rd -UPDATES RFC 2845 Motorola Laboratories -Expires: February 2005 August 2004 - - - HMAC SHA TSIG Algorithm Identifiers - ---- --- ---- --------- ----------- - <draft-ietf-dnsext-tsig-sha-00.txt> - - -Status of This Document - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - or will be disclosed, and any of which I become aware will be - disclosed, in accordance with RFC 3668. - - This draft is intended to be become a Proposed Standard RFC. - Distribution of this document is unlimited. Comments should be sent - to the DNSEXT working group mailing list <namedroppers@ops.ietf.org>. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than a "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - -Abstract - - Use of the TSIG DNS resource record requires specification of a - cryptographic message authentication code. Currently identifiers - have been specified only for the HMAC-MD5 and GSS TSIG algorithms. - This document standardizes identifiers for additional HMAC SHA TSIG - algorithms and standardizes how to specify the truncation of HMAC - values. - - -Copyright Notice - - Copyright (C) The Internet Society 2004. All Rights Reserved. - - - - -D. Eastlake 3rd [Page 1] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Table of Contents - - Status of This Document....................................1 - Abstract...................................................1 - Copyright Notice...........................................1 - - Table of Contents..........................................2 - - 1. Introduction............................................3 - - 2. Algorithms and Identifiers..............................4 - - 3. Specifying Truncation...................................5 - - 4. IANA Considerations.....................................6 - 5. Security Considerations.................................6 - 6. Copyright and Disclaimer................................6 - - 7. Normative References....................................7 - 8. Informative References..................................7 - - Authors Address............................................8 - Expiration and File Name...................................8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 2] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -1. Introduction - - [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to - authenticate DNS queries and responses. This RR contains a domain - name syntax data item which names the authentication algorithm used. - [RFC 2845] defines the HMAC-MD5.SIG-ALG.REG.INT name for - authentication codes using the HMAC [RFC 2104] algorithm with the MD5 - [RFC 1321] hash algorithm. IANA has also registered "gss-tsig" as an - identifier for TSIG authentication where the cryptographic operations - are delegated to GSS [RFC 3645]. - - In section 2, this document specifies additional names for TSIG - authentication algorithms based on US NIST SHA algorithms and HMAC. - - In section 3, this document specifies the meaning of inequality - between the normal output size of the specified hash function and the - length of MAC (message authentication code) data given in the TSIG - RR. In particular, it specifies that a shorter length field value - specifies truncation and a longer length field is an error. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 3] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -2. Algorithms and Identifiers - - TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS - queries and responses. They are intended to be efficient symmetric - authentication codes based on a shared secret. (Asymmetric signatures - can be provided using the SIG RR [RFC 2931]. In particular, SIG(0) - can be used for transaction signatures.) Used with a strong hash - function, HMAC [RFC 2104] provides a way to calculate such symmetric - authentication codes. The only specified HMAC based TSIG algorithm - identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321]. - - The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as - compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512 - bits, may be preferred in some case. Use of TSIG between a DNS - resolver and server is by mutual agreement. That agreement can - include the support of additional algorithms. - - For completeness in relation to HMAC based algorithms, the current - HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below. - Implementations which support TSIG MUST implement HMAC MD5, SHOULD - implement HMAC SHA-1, and MAY implement gss-tsig and the other - algorithms listed below. - - Mandatory HMAC-MD5.SIG-ALG.REG.INT - Recommended hmac-sha1 - Optional hmac-sha224 - Optional hmac-sha256 - Optional hamc-sha384 - Optional hmac-sha512 - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 4] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -3. Specifying Truncation - - In some cases, it is reasonable to truncate the output of HMAC and - use the truncated value for authentication. HMAC SHA-1 truncated to - 96 bits is an optional available in several IETF protocols including - IPSEC and TLS. - - The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the - size of the MAC field in octets. But [RFC 2845] does not specify what - to do if this MAC size differs from the length of the output of HMAC - for a particular hash function. - - The specification for TSIG handling is changed as follows: - - 1. If The "MAC size" field is larger than the HMAC output length or - is zero: This case MUST NOT be generated and if received MUST - cause the packet to be dropped and RCODE 1 (FORMERR) to be - returned. - - 2. If the "MAC size" field equals the HMAC output length: Operation - is as described in [RFC 2845]. - - 3. If the "MAC size" field is less than the HMAC output length but is - not zero: This is sent when the signer has truncated the HMAC - output as described in RFC 2104, taking initial octets and - discarding trailing octets. TSIG truncation can only be to an - integral number of octets. On receipt of a packet with truncation - thus indicated, the locally calculated MAC is similarly truncated - and only the truncated values compared for authentication. - - TSIG implementations SHOULD implement SHA-1 truncated to 96 bits (12 - octets) and MAY implement any or all other truncations valid under - case 3 above. - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 5] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -4. IANA Considerations - - This document, on approval for publication as a standards track RFC, - registers the new TSIG algorithm identifiers listed in Section 2 with - IANA. - - - -5. Security Considerations - - For all of the message authentication code algorithms listed herein, - those producing longer values are believed to be stronger; however, - while there are some arguments that mild truncation can strengthen a - MAC by reducing the information available to an attacker, excessive - truncation clearly weakens authentication by reducing the number of - bits an attacker has to try to force. See [RFC 2104] which recommends - that ah HMAC never be truncated to less than half its length nor to - less than 80 bits (10 octets). - - See also the Security Considerations section of [RFC 2845]. - - - -6. Copyright and Disclaimer - - Copyright (C) The Internet Society 2004. This document is subject to - the rights, licenses and restrictions contained in BCP 78 and except - as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 6] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -7. Normative References - - [FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal - Information Processing Standard, Draft, 1 August 2002. - - [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC - 1321, April 1992. - - [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, February 1997. - - [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", - RFC 2845, May 2000. - - [RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R. - Housley, December 2003, work in progress, draft-ietf-pkix- - sha224-*.txt. - - - -8. Informative References. - - [FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information - Processing Standard, 17 April 1995. - - [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction - Signatures ( SIG(0)s )", RFC 2931, September 2000. - - [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC 3645] - Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, - J., and R. Hall, "Generic Security Service Algorithm for Secret Key - Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October - 2003. - - - - - - - - - - - - - -D. Eastlake 3rd [Page 7] - - -INTERNET-DRAFT HMAC-SHA TSIG Identifiers - - -Authors Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Telephone: +1-508-786-7554 (w) - +1-508-634-2066 (h) - EMail: Donald.Eastlake@motorola.com - - - -Expiration and File Name - - This draft expires in February 2005. - - Its file name is draft-ietf-dnsext-tsig-sha-00.txt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd [Page 8] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt deleted file mode 100644 index d65fa7104251c..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-02.txt +++ /dev/null @@ -1,1010 +0,0 @@ - - - - - - -dnsext Working Group B. Halley -Internet Draft Nominum -Expiration Date: March 2004 - E. Lewis - ARIN - - September 2003 - - - Clarifying the Role of Wild Card Domains - in the Domain Name System - - - draft-ietf-dnsext-wcard-clarify-02.txt - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - -Abstract - - The definition of wild cards is recast from the original in RFC 1034, - in words that are more specific and in line with RFC 2119. This - document is meant to supplement the definition in RFC 1034 and to - alter neither the spirit nor intent of that definition. - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 1] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Table of Contents - - Abstract ................................................ 1 - 1 Introduction ............................................ 2 - 1.1 Document Limits ......................................... 3 - 1.2 Existence ............................................... 4 - 1.3 An Example .............................................. 4 - 1.4 Empty Non-terminals ..................................... 5 - 1.5 Terminology ............................................. 6 - 2 Defining the Wild Card Domain Name ...................... 7 - 3 Defining Existence ...................................... 8 - 4 Impact of a Wild Card In a Query or in RDATA ............ 8 - 5 Impact of a Wild Card Domain On a Response .............. 9 - 6 Considerations with Special Types ....................... 12 - 6.1 SOA RR's at a Wild Card Domain Name ..................... 12 - 6.2 NS RR's at a Wild Card Domain Name ...................... 12 - 6.3 CNAME RR's at a Wild Card Domain Name ................... 13 - 6.4 DNAME RR's at a Wild Card Domain Name ................... 13 - 7 Security Considerations ................................. 14 - 8 References .............................................. 14 - 9 Others Contributing to This Document .................... 14 - 10 Editors ................................................. 15 - Appendix A: Subdomains of Wild Card Domain Names ........ 16 - Full Copyright Statement ................................ 18 - Acknowledgement ......................................... 18 - - - - -1. Introduction - - The first section of this document will give a crisp overview of what - is begin defined, as well as the motivation rewording of an original - document and making a change to bring the specification in line with - implementations. Examples are included to help orient the reader. - - Wild card domain names are defined in Section 4.3.3. of RFC 1034 as - "instructions for synthesizing RRs." [RFC1034]. The meaning of this - is that a specific, special domain name is used to construct - responses in instances in which the query name is not otherwise - represented in a zone. - - A wild card domain name has a specific range of influence on query - names (QNAMEs) within a given class, which is rooted at the domain - name containing the wild card label, and is limited by explicit - entries, zone cuts and empty non-terminal domains (see section 1.3 of - this document). - - - - -Halley & Lewis [Expires March 2004] [Page 2] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Note that a wild card domain name has no special impact on the search - for a query type (QTYPE). If a domain name is found that matches the - QNAME (exact or a wild card) but the QTYPE is not found at that - point, the proper response is that there is no data available. The - search does not continue on to seek other wild cards that might match - the QTYPE. To illustrate, a wild card owning an MX RR does not - 'cover' other names in the zone that own an A RR. There are certain - special case RR types that will be singled out for discussion, the - SOA RR, NS RR, CNAME RR, and DNAME RR. - - Why is this document needed? Empirical evidence suggests that the - words in RFC 1034 are not clear enough. There exist a number of - implementations that have strayed (each differently) from that - definition. There also exists a misconception of operators that the - wild card can be used to add a specific RR type to all names, such as - the MX RR example cited above. This document is also needed as input - to efforts to extend DNS, such as the DNS Security Extensions [RFC - 2535]. Lack of a clear base specification has proven to result in - extension documents that have unpredictable consequences. (This is - true in general, not just for DNS.) - - Another reason this clarification is needed is to answer questions - regarding authenticated denial of existence, a service introduced in - the DNS Security Extensions [RFC 2535]. Prior to the work leading up - to this document, it had been feared that a large number of proof - records (NXTs) might be needed in each reply because of the unknown - number of potential wild card domains that were thought to be - applicable. One outcome of this fear is a now discontinued document - solving a problem that is now known not to exist. I.e., this - clarification has the impact of defending against unwarranted - protocol surgery. It is not "yet another" effort to just rewrite the - early specifications for the sake of purity. - - Although the effort to define the DNS Security Extensions has - prompted this document, the clarifications herein relate to basic DNS - only. No DNS Security Extensions considerations are mentioned in the - document. - -1.1. Document Limits - - This document limits itself to reinforcing the concepts in RFC 1034. - In the effort to do this, a few issues have been discussed that - change parts of what is in RFC 1034. The discussions have been held - within the DNS Extensions Working Group. - - - - - - - -Halley & Lewis [Expires March 2004] [Page 3] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Briefly, the issues raised include: - - The lack of clarity in the definition of domain name existence - - Implications of a wild card domain name owning any of the - following resource record sets: DNAME [RFC 2672], CNAME, NS, and - SOA - - Whether RFC 1034 meant to allow special processing of CNAME RR's - owned by wild card domain names - -1.2. Existence - - The notion that a domain name 'exists' will arise numerous times in - this discussion. RFC 1034 raises the issue of existence in a number - of places, usually in reference to non-existence and often in - reference to processing involving wild card domain names. RFC 1034 - contains algorithms that describe how domain names impact the - preparation of an answer and does define wild cards as a means of - synthesizing answers. Because of this a discussion on wild card - domain names has to start with the issue of existence. - - To help clarify the topic of wild cards, a positive definition of - existence is needed. Complicating matters, though, is the - realization that existence is relative. To an authoritative server, - a domain name exists if the domain name plays a role following the - algorithms of preparing a response. To a resolver, a domain name - exists if there is any data available corresponding to the name. The - difference between the two is the synthesis of records according to a - wild card. - - For the purposes of this document, the point of view of an - authoritative server is adopted. A domain name is said to exist if - it plays a role in the execution of the algorithms in RFC 1034. - -1.3. An Example - - For example, consider this wild card domain name: *.example. Any - query name under example. is a candidate to be matched (answered) by - this wild card, i.e., to have an response returned that is - synthesized from the wild card's RR sets. Although any name is a - candidate, not all queries will match. - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 4] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - To further illustrate this, consider this zone: - - $ORIGIN example. - @ IN SOA - NS - NS - * TXT "this is a wild card" - MX 10 mailhost.example. - host1 A 10.0.0.1 - _ssh._tcp.host1 SRV - _ssh._tcp.host2 SRV - subdel NS - - - The following queries would be synthesized from the wild card: - - QNAME=host3.example. QTYPE=MX, QCLASS=IN - the answer will be a "host3.example. IN MX ..." - QNAME=host3.example. QTYPE=A, QCLASS=IN - the answer will reflect "no error, but no data" - because there is no A RR set at '*' - - The following queries would not be synthesized from the wild card: - - QNAME=host1.example., QTYPE=MX, QCLASS=IN - because host1.example. exists - QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN - because _tcp.host1.example. exists (without data) - QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN - because host2.example. exists (without data) - QNAME=host.subdel.example., QTYPE=A, QCLASS=IN - because subdel.example. exists and is a zone cut - - To the server, the following domains are considered to exist in the - zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, - _ssh._tcp.host2, and subdel. To a resolver, many more domains appear - to exist via the synthesis of the wild card. - -1.4. Empty Non-terminals - - Empty non-terminals are domain names that own no data but have - subdomains. This is defined in section 3.1 of RFC 1034: - -# The domain name space is a tree structure. Each node and leaf on the -# tree corresponds to a resource set (which may be empty). The domain -# system makes no distinctions between the uses of the interior nodes and -# leaves, and this memo uses the term "node" to refer to both. - - - - -Halley & Lewis [Expires March 2004] [Page 5] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - The parenthesized "which may be empty" specifies that empty non- - terminals are explicitly recognized. According to the definition of - existence in this document, empty non-terminals do exist at the - server. - - Carefully reading the above paragraph can lead to an interpretation - that all possible domains exist - up to the suggested limit of 255 - octets for a domain name [RFC 1035]. For example, www.example. may - have an A RR, and as far as is practically concerned, is a leaf of - the domain tree. But the definition can be taken to mean that - sub.www.example. also exists, albeit with no data. By extension, all - possible domains exist, from the root on down. As RFC 1034 also - defines "an authoritative name error indicating that the name does - not exist" in section 4.3.1, this is not the intent of the original - document. - - RFC1034's wording is to be clarified by adding the following - paragraph: - - A node is considered to have an impact on the algorithms of - 4.3.2 if it is a leaf node with any resource sets or an interior - node, with or without a resource set, that has a subdomain that - is a leaf node with a resource set. A QNAME and QCLASS matching - an existing node never results in a response return code of - authoritative name error. - - The terminology in the above paragraph is chosen to remain as close - to that in the original document. The term "with" is a alternate - form for "owning" in this case, hence "a leaf node owning resources - sets, or an interior node, owning or not owning any resource set, - that has a leaf node owning a resource set as a subdomain," is the - proper interpretation of the middle sentence. - - As an aside, an "authoritative name error" has been called NXDOMAIN - in some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic - assigned to such an error by at least one implementation of DNS. As - this mnemonic is specific to implementations, it is avoided in the - remainder of this document. - -1.5. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in the document entitled - "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] - - Requirements are denoted by paragraphs that begin with with the - following convention: 'R'<sect>.<count>. - - - -Halley & Lewis [Expires March 2004] [Page 6] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Quotations of RFC 1034 (as has already been done once above) are - denoted by a '#' in the leftmost column. - -2. Defining the Wild Card Domain Name - - A wild card domain name is defined by having the initial label be: - - 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) - - This defines domain names that may play a role in being a wild card, - that is, being a source for synthesized answers. Domain names - conforming to this definition that appear in queries and RDATA - sections do not have any special role. These cases will be described - in more detail in following sections. - - R2.1 A domain name that is to be interpreted as a wild card MUST - begin with a label of '0000 0001 0010 1010' in binary. - - The first octet is the normal label type and length for a 1 octet - long label, the second octet is the ASCII representation [RFC 20] for - the '*' character. In RFC 1034, ASCII encoding is assumed to be the - character encoding. - - In the master file formats used in RFCs, a "*" is a legal - representation for the wild card label. Even if the "*" is escaped, - it is still interpreted as the wild card when it is the only - character in the label. - - R2.2 A server MUST treat a wild card domain name as the basis of - synthesized answers regardless of any "escape" sequences in the - input format. - - RFC 1034 and RFC 1035 ignore the case in which a domain name might be - "the*.example.com." The interpretation is that this domain name in a - zone would only match queries for "the*.example.com" and not have any - other role. - - Note: By virtue of this definition, a wild card domain name may have - a subdomain. The subdomain (or sub-subdomain) itself may also be a - wild card. E.g., *.*.example. is a wild card, so is *.sub.*.example. - More discussion on this is given in Appendix A. - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 7] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -3. Defining Existence - - As described in the Introduction, a precise definition of existence - is needed. - - R3.1 An authoritative server MUST treat a domain name as existing - during the execution of the algorithms in RFC 1034 when the - domain name conforms to the following definition. A domain name - is defined to exist if the domain name owns data and/or has a - subdomain that exists. - - Note that at a zone boundary, the domain name owns data, including - the NS RR set. At the delegating server, the NS RR set is not - authoritative, but that is of no consequence here. The domain name - owns data, therefore, it exists. - - R3.2 An authoritative server MUST treat a domain name that has - neither a resource record set nor an existing subdomain as non- - existent when executing the algorithm in section 4.3.2. of RFC - 1034. - - A note on terminology. A domain transcends zones, i.e., all DNS data - is in the root domain but segmented into zones of control. In this - document, there are references to a "domain name" in the context of - existing "in a zone." In this usage, a domain name is the root of a - domain, not the entire domain. The domain's root point is said to - "exist in a zone" if the zone is authoritative for the name. RR sets - existing in a domain need not be owned by the domain's root domain - name, but are owned by other domain names in the domain. - -4. Impact of a Wild Card In a Query or in RDATA - - When a wild card domain name appears in a question, e.g., the query - name is "*.example.", the response in no way differs from any other - query. In other words, the wild card label in a QNAME has no special - meaning, and query processing will proceed using '*' as a literal - query name. - - R4.1 A wild card domain name acting as a QNAME MUST be treated as any - other QNAME, there MUST be no special processing accorded it. - - If a wild card domain name appears in the RDATA of a CNAME RR or any - other RR that has a domain name in it, the same rule applies. In the - instance of a CNAME RR, the wild card domain name is used in the same - manner of as being the original QNAME. For other RR's, rules vary - regarding what is done with the domain name(s) appearing in them, in - no case does the wild card hold special meaning. - - - - -Halley & Lewis [Expires March 2004] [Page 8] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - R4.2 A wild card domain name appearing in any RR's RDATA MUST be - treated as any other domain name in that situation, there MUST - be no special processing accorded it. - -5. Impact of a Wild Card Domain On a Response - - The description of how wild cards impact response generation is in - RFC 1034, section 4.3.2. That passage contains the algorithm - followed by a server in constructing a response. Within that - algorithm, step 3, part 'c' defines the behavior of the wild card. - The algorithm is directly quoted in lines that begin with a '#' sign. - Commentary is interleaved. - - There is a documentation issue deserving some explanation. The - algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo - code, i.e., it's steps are not intended to be followed in strict - order. The "algorithm" is a suggestion. As such, in step 3, parts - a, b, and c, do not have to be implemented in that order. - - Another issue needing explanation is that RFC 1034 is a full - standard. There is another RFC, RFC 2672, which makes, or proposes - an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME - RR. RFC 2672 is a proposed standard. The dilemma in writing these - clarifications is knowing which document is the one being clarified. - Fortunately, the difference between RFC 1034 and RFC 2672 is not - significant with respect to wild card synthesis, so this document - will continue to state that it is clarifying RFC 1034. If RFC 2672 - progresses along the standards track, it will need to refer to - modifying RFC 1034's algorithm as amended here. - - The context of part 'c' is that the search is progressing label by - label through the QNAME. (Note that the data being searched is the - authoritative data in the server, the cache is searched in step 4.) - Step 3's part 'a' covers the case that the QNAME has been matched in - full, regardless of the presence of a CNAME RR. Step 'b' covers - crossing a cut point, resulting in a referral. All that is left is - to look for the wild card. - - Step 3 of the algorithm also assumes that the search is looking in - the zone closest to the answer, i.e., in the same class as QCLASS and - as close to the authority as possible on this server. If the zone is - not the authority, then a referral is given, possibly one indicating - lameness. - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 9] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -# c. If at some label, a match is impossible (i.e., the -# corresponding label does not exist), look to see if a -# the "*" label exists. - - The above paragraph refers to finding the domain name that exists in - the zone and that most encloses the QNAME. Such a domain name will - mark the boundary of candidate wild card domain names that might be - used to synthesize an answer. (Remember that at this point, if the - most enclosing name is the same as the QNAME, part 'a' would have - recorded an exact match.) The existence of the enclosing name means - that no wild card name higher in the tree is a candidate to answer - the query. - - Once the closest enclosing node is identified, there's the matter of - what exists below it. It may have subdomains, but none will be - closer to the QNAME. One of the subdomains just might be a wild - card. If it exists, this is the only wild card eligible to be used - to synthesize an answer for the query. Even if the closest enclosing - node conforms to the syntax rule in section 2 for being a wild card - domain name, the closest enclosing node is not eligible to be a - source of a synthesized answer. - - The only wild card domain name that is a candidate to synthesize an - answer will be the "*" subdomain of the closest enclosing domain - name. Three possibilities can happen. The "*" subdomain does not - exist, the "*" subdomain does but does not have an RR set of the same - type as the QTYPE, or it exists and has the desired RR set. - - For the sake of brevity, the closest enclosing node can be referred - to as the "closest encloser." The closest encloser is the most - important concept in this clarification. Describing the closest - encloser is a bit tricky, but it is an easy concept. - - To find the closest encloser, you have to first locate the zone that - is the authority for the query name. This eliminates the need to be - concerned that the closest encloser is a cut point. In addition, we - can assume too that the query name does not exist, hence the closest - encloser is not equal to the query name. We can assume away these - two cases because they are handled in steps 2, 3a and 3b of section - 4.3.2.'s algorithm. - - What is left is to identify the existing domain name that would have - been up the tree (closer to the root) from the query name. Knowing - that an exact match is impossible, if there is a "*" label descending - from the unique closest encloser, this is the one and only wild card - from which an answer can be synthesized for the query. - - - - - -Halley & Lewis [Expires March 2004] [Page 10] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - To illustrate, using the example in section 1.2 of this document, the - following chart shows QNAMEs and the closest enclosers. In - Appendix A there is another chart showing unusual cases. - - QNAME Closest Encloser Wild Card Source - host3.example. example. *.example. - _telnet._tcp.host1.example. _tcp.host1.example. no wild card - _telnet._tcp.host2.example. host2.example. no wild card - _telnet._tcp.host3.example. example. *.example. - _chat._udp.host3.example. example. *.example. - - Note that host1.subdel.example. is in a subzone, so the search for it - ends in a referral in part 'b', thus does not enter into finding a - closest encloser. - - The fact that a closest encloser will be the only superdomain that - can have a candidate wild card will have an impact when it comes to - designing authenticated denial of existence proofs. - -# If the "*" label does not exist, check whether the name -# we are looking for is the original QNAME in the query -# or a name we have followed due to a CNAME. If the name -# is original, set an authoritative name error in the -# response and exit. Otherwise just exit. - - The above passage says that if there is not even a wild card domain - name to match at this point (failing to find an explicit answer - elsewhere), we are to return an authoritative name error at this - point. If we were following a CNAME, the specification is unclear, - but seems to imply that a no error return code is appropriate, with - just the CNAME RR (or sequence of CNAME RRs) in the answer section. - -# If the "*" label does exist, match RRs at that node -# against QTYPE. If any match, copy them into the answer -# section, but set the owner of the RR to be QNAME, and -# not the node with the "*" label. Go to step 6. - - This final paragraph covers the role of the QTYPE in the process. - Note that if no resource record set matches the QTYPE the result is - that no data is copied, but the search still ceases ("Go to step - 6."). In the following section, a suggested change is made to this, - under the heading "CNAME RRs at a Wild Card Domain Name." - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 11] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -6. Considerations with Special Types - - For the purposes of this section, "special" means that a record - induces processing at the server beyond simple lookup. The special - types in this section are SOA, NS, CNAME, and DNAME. SOA is special - because it is used as a zone marker and has an impact on step 2 of - the algorithm in 4.3.2. NS denotes a cut point and has an impact on - step 3b. CNAME redirects the query and is mentioned in steps 3a and - 3b. DNAME is a "CNAME generator." - -6.1. SOA RR's at a Wild Card Domain Name - - If the owner of an SOA record conforms to the basic rules of owning - an SOA RR (meaning it is the apex of a zone) the impact on the search - algorithm is not in section 3c (where records are synthesized) as - would be expected. The impact is really in step 2 of the algorithm, - the choice of zone. - - We are no longer talking about whether or not an SOA RR can be - synthesized in a response because we are shifting attention to step - 2. We are now talking about what it means for a name server to - synthesize a zone for a response. To date, no implementation has - done this. Thinking ahead though, anyone choosing to pursue this - would have to be aware that a server would have to be able to - distinguish between queries for data it will have to synthesize and - queries that ought to be treated as if they were prompted by a lame - delegation. - - It is not a protocol error to have an SOA RR owned by a wild card - domain name, just as it is not an error to have zone name be - syntactically equivalent to a domain name. However, this situation - requires careful consideration of how a server chooses the - appropriate zone for an answer. And an SOA RR is not able to be - synthesized as in step 3c. - -6.2. NS RR's at a Wild Card Domain Name - - Complimentary to the issue of an SOA RR owned by a wild card domain - name is the issue of NS RR's owned by a wild card domain name. In - this instance, each machine being referred to in the RDATA of the NS - RR has to be able to understand the impact of this on step 2, the - choosing of the authoritative zone. - - Referring to the same machine in such a NS RR will probably not work - well. This is because the server may become confused as to whether - the query name ought to be answered by the zone owning the NS RR in - question or a synthesized zone. (It isn't known in advance that the - query name will invoke the wild card synthesis.) - - - -Halley & Lewis [Expires March 2004] [Page 12] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - The status of other RR's owned by a wild card domain name is the same - as if the owner name was not a wild card domain name. I.e., when - there is a NS RR at a wild card domain name, other records are - treated as being below the zone cut. - - Is it not a protocol error to have a NS RR owned by a wild card - domian name, complimentary to the case of a SOA RR. However, for - this to work, an implementation has to know how to synthesize a zone. - -6.3. CNAME RR's at a Wild Card Domain Name - - The issue of CNAME RR's owned by wild card domain names has prompted - a suggested change to the last paragraph of step 3c of the algorithm - in 4.3.2. The changed text is this: - - If the "*" label does exist and if the data at the node is a - CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the - answer section of the response, set the owner of the CNAME RR to - be QNAME, and then change QNAME to the canonical name in the - CNAME RR, and go back to step 1. - - If the "*" label does exist and either QTYPE is CNAME or the - data at the node is not a CNAME, then match RRs at that node - against QTYPE. If any match, copy them into the answer section, - but set the owner of the RR to be QNAME, and not the node with - the "*" label. Go to step 6. - - Apologies if the above isn't clear, but an attempt was made to stitch - together the passage using just the phrases in section 3a and 3c of - the algorithm so as to preserve the original flavor. - - In case the passage as suggested isn't clear enough, the intent is to - make "landing" at a wild card name and finding a CNAME the same as if - this happened as a result of a direct match. I.e., Finding a CNAME - at the name matched in step 3c is supposed to have the same impact as - finding the CNAME in step 3a. - -6.4. DNAME RR's at a Wild Card Domain Name - - The specification of the DNAME RR, which is at the proposed level of - standardization, is not as mature as the full standard in RFC 1034. - Because of this, or the reason for this is, there appears to be a - host of issues with that definition and it's rewrite of the algorithm - in 4.3.2. For the time being, when it comes to wild card processing - issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME - at a wild card domain name is effectively the same as a CNAME at a - wild card domain name. - - - - -Halley & Lewis [Expires March 2004] [Page 13] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -7. Security Considerations - - This document is refining the specifications to make it more likely - that security can be added to DNS. No functional additions are being - made, just refining what is considered proper to allow the DNS, - security of the DNS, and extending the DNS to be more predictable. - -8. References - - Normative References - - [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 - - [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, - Nov-01-1987 - - [RFC 1035] Domain Names - Implementation and Specification, P.V - Mockapetris, Nov-01-1987 - - [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S - Bradner, March 1997 - - Informative References - - [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, - Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 - - [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 - - [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999 - -9. Others Contributing to This Document - - Others who have directly caused text to appear in the document: Paul - Vixie and Olaf Kolkman. Many others have indirect influences on the - content. - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 14] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -10. Editors - - Name: Bob Halley - Affiliation: Nominum, Inc. - Address: 2385 Bay Road, Redwood City, CA 94063 USA - Phone: +1-650-381-6016 - EMail: Bob.Halley@nominum.com - - Name: Edward Lewis - Affiliation: ARIN - Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA - Phone: +1-703-227-9854 - Email: edlewis@arin.net - - Comments on this document can be sent to the editors or the mailing - list for the DNSEXT WG, namedroppers@ops.ietf.org. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 15] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Appendix A: Subdomains of Wild Card Domain Names - - In reading the definition of section 2 carefully, it is possible to - rationalize unusual names as legal. In the example given, - *.example. could have subdomains of *.sub.*.example. and even the - more direct *.*.example. (The implication here is that these domain - names own explicit resource records sets.) Although defining these - names is not easy to justify, it is important that implementions - account for the possibility. This section will give some further - guidence on handling these names. - - The first thing to realize is that by all definitions, subdomains of - wild card domain names are legal. In analyzing them, one realizes - that they cause no harm by their existence. Because of this, they - are allowed to exist, i.e., there are no special case rules made to - disallow them. The reason for not preventing these names is that the - prevention would just introduce more code paths to put into - implementations. - - The concept of "closest enclosing" existing names is important to - keep in mind. It is also important to realize that a wild card - domain name can be a closest encloser of a query name. For example, - if *.*.example. is defined in a zone, and the query name is - a.*.example., then the closest enclosing domain name is *.example. - Keep in mind that the closest encloser is not eligible to be a source - of synthesized answers, just the subdomain of it that has the first - label "*". - - To illustrate this, the following chart shows some matches. Assume - that the names *.example., *.*.example., and *.sub.*.example. are - defined in the zone. - - QNAME Closest Encloser Wild Card Source - a.example. example. *.example. - b.a.example. example. *.example. - a.*.example. *.example. *.*.example. - b.a.*.example. *.example. *.*.example. - b.a.*.*.example. *.*.example. no wild card - a.sub.*.example. sub.*.example. *.sub.*.example. - b.a.sub.*.example. sub.*.example. *.sub.*.example. - a.*.sub.*.example. *.sub.*.example. no wild card - *.a.example. example. *.example. - a.sub.b.example. example. *.example. - - Recall that the closest encloser itself cannot be the wild card. - Therefore the match for b.a.*.*.example. has no applicable wild card. - - - - - -Halley & Lewis [Expires March 2004] [Page 16] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - - Finally, if a query name is sub.*.example., any answer available will - come from an exact name match for sub.*.example. No wild card - synthesis is performed in this case. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 17] - -Internet Draft draft-ietf-dnsext-wcard-clarify-02.txt September 2003 - - -Full Copyright Statement - - Copyright (C) The Internet Society 2003. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Halley & Lewis [Expires March 2004] [Page 18] diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt deleted file mode 100644 index e9943015e4e97..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt +++ /dev/null @@ -1,1120 +0,0 @@ - - -DNS Operations M. Larson -Internet-Draft P. Barber -Expires: August 16, 2004 VeriSign - February 16, 2004 - - - Observed DNS Resolution Misbehavior - draft-ietf-dnsop-bad-dns-res-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This Internet-Draft describes DNS name server and resolver behavior - that results in a significant query volume sent to the root and - top-level domain (TLD) name servers. In some cases we recommend - minor additions to the DNS protocol specification and corresponding - changes in name server implementations to alleviate these unnecessary - queries. The recommendations made in this document are a direct - byproduct of observation and analysis of abnormal query traffic - patterns seen at two of the thirteen root name servers and all - thirteen com/net TLD name servers. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Larson & Barber Expires August 16, 2004 [Page 1] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - document are to be interpreted as described in RFC 2119 [1]. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Observed name server misbehavior . . . . . . . . . . . . . 4 - 2.1 Aggressive requerying for delegation information . . . . . 4 - 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5 - 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6 - 2.3 Inability to follow multiple levels of out-of-zone glue . 6 - 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7 - 2.4 Aggressive retransmission when fetching glue . . . . . . . 7 - 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8 - 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 - 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9 - 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10 - 2.7 Name server records with zero TTL . . . . . . . . . . . . 10 - 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11 - 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 - 2.9 Queries for domain names resembling IP addresses . . . . . 12 - 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12 - 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12 - 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 2.11 Suboptimal name server selection algorithm . . . . . . . . 13 - 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 - 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15 - 4. Security considerations . . . . . . . . . . . . . . . . . 16 - 5. Internationalization considerations . . . . . . . . . . . 17 - Normative References . . . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 - Intellectual Property and Copyright Statements . . . . . . 19 - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 2] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -1. Introduction - - Observation of query traffic received by two root name servers and - the thirteen com/net TLD name servers has revealed that a large - proportion of the total traffic often consists of "requeries". A - requery is the same question (<qname, qtype, qclass>) asked - repeatedly at an unexpectedly high rate. We have observed requeries - from both a single IP address and multiple IP addresses. - - By analyzing requery events we have found that the cause of the - duplicate traffic is almost always a deficient name server, stub - resolver and/or application implementation combined with an - operational anomaly. The implementation deficiencies we have - identified to date include well-intentioned recovery attempts gone - awry, insufficient caching of failures, early abort when multiple - levels of glue records must be followed, and aggressive retry by stub - resolvers and/or applications. Anomalies that we have seen trigger - requery events include lame delegations, unusual glue records, and - anything that makes all authoritative name servers for a zone - unreachable (DoS attacks, crashes, maintenance, routing failures, - congestion, etc.). - - In the following sections, we provide a detailed explanation of the - observed behavior and recommend changes that will reduce the requery - rate. Some of the changes recommended affect the core DNS protocol - specification, described principally in RFC 1034 [2], RFC 1035 [3] - and RFC 2181 [4]. - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 3] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2. Observed name server misbehavior - -2.1 Aggressive requerying for delegation information - - There can be times when every name server in a zone's NS RRset is - unreachable (e.g., during a network outage), unavailable (e.g., the - name server process is not running on the server host) or - misconfigured (e.g., the name server is not authoritative for the - given zone, also known as "lame"). Consider a recursive name server - that attempts to resolve a query for a domain name in such a zone and - discovers that none of the zone's name servers can provide an answer. - We have observed a recursive name server implementation that then - verifies the zone's NS RRset in its cache by querying for the zone's - delegation information: it sends a query for the zone's NS RRset to - one of the parent zone's name servers. - - For example, suppose that "example.com" has the following NS RRset: - - example.com. IN NS ns1.example.com. - example.com. IN NS ns2.example.com. - - Upon receipt of a query for "www.example.com" and assuming that - neither "ns1.example.com" nor "ns2.example.com" can provide an - answer, this recursive name server implementation immediately queries - a "com" zone name server for the "example.com" NS RRset to verify it - has the proper delegation information. This name server - implementation performs this query to a zone's parent zone for each - recursive query it receives that fails because of a completely - unresponsive set of name servers for the target zone. Consider the - effect when a popular zone experiences a catastrophic failure of all - its name servers: now every recursive query for domain names in that - zone sent to this name server implementation results in a query to - the failed zone's parent name servers. On one occasion when several - dozen popular zones became unreachable, the query load on the com/net - name servers increased by 50%. - - We believe this verification query is not reasonable. Consider the - circumstances: When a recursive name server is resolving a query for - a domain name in a zone it has not previously searched, it uses the - list of name servers in the referral from the target zone's parent. - If on its first attempt to search the target zone, none of the name - servers in the referral is reachable, a verification query to the - parent is pointless: this query to the parent would come so quickly - on the heels of the referral that it would be almost certain to - contain the same list of name servers. The chance of discovering any - new information is slim. - - The other possibility is that the recursive name server successfully - - - -Larson & Barber Expires August 16, 2004 [Page 4] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - contacts one of the target zone's name servers and then caches the NS - RRset from the authority section of a response, the proper behavior - according to section 5.4.1 of RFC 2181 [4], because the NS RRset from - the target zone is more trustworthy than delegation information from - the parent zone. If, while processing a subsequent recursive query, - the recursing name server discovers that none of the name servers - specified in the cached NS RRset is available or authoritative, - querying the parent would be wrong. An NS RRset from the parent zone - would now be less trustworthy than data already in the cache. - - For this query of the parent zone to be useful, the target zone's - entire set of name servers would have to change AND the former set of - name servers would have to be deconfigured and/or decommissioned AND - the delegation information in the parent zone would have to be - updated with the new set of name servers, all within the TTL of the - target zone's NS RRset. We believe this scenario is uncommon: - administrative best practices dictate that changes to a zone's set of - name servers happen gradually, with servers that are removed from the - NS RRset left authoritative for the zone as long as possible. The - scenarios that we can envision that would benefit from the parent - requery behavior do not outweigh its damaging effects. - -2.1.1 Recommendation - - Name servers offering recursion MUST NOT send a query for the NS - RRset of a non-responsive zone to any of the name servers for that - zone's parent zone. For the purposes of this injunction, a - non-responsive zone is defined as a zone for which every name server - listed in the zone's NS RRset: - - 1. is not authoritative for the zone (i.e., lame), or, - - 2. returns a server failure response (RCODE=2), or, - - 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. - - -2.2 Repeated queries to lame servers - - Section 2.1 describes a catastrophic failure: when every name server - for a zone is unable to provide an answer for one reason or another. - A more common occurrence is a subset of a zone's name servers being - unavailable or misconfigured. Different failure modes have different - expected durations. Some symptoms indicate problems that are - potentially transient: various types of ICMP unreachable messages - because a name server process is not running or a host or network is - unreachable, or a complete lack of a response to a query. Such - responses could be the result of a host rebooting or temporary - - - -Larson & Barber Expires August 16, 2004 [Page 5] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - outages; these events don't necessarily require any human - intervention and can be reasonably expected to be temporary. - - Other symptoms clearly indicate a condition requiring human - intervention, such as lame server: if a name server is misconfigured - and not authoritative for a zone delegated to it, it is reasonable to - assume that this condition has potential to last longer than - unreachability or unresponsiveness. Consequently, repeated queries - to known lame servers are not useful. In this case of a condition - with potential to persist for a long time, a better practice would be - to maintain a list of known lame servers and avoid querying them - repeatedly in a short interval. - -2.2.1 Recommendation - - Recursive name servers SHOULD cache name servers that they discover - are not authoritative for zones delegated to them (i.e. lame - servers). Lame servers MUST be cached against the specific query - tuple <zone name, class, server IP address>. Zone name can be - derived from the owner name of the NS record that was referenced to - query the name server that was discovered to be lame. - Implementations that perform lame server caching MUST refrain from - sending queries to known lame servers based on a time interval from - when the server is discovered to be lame. A minimum interval of - thirty minutes is RECOMMENDED. - -2.3 Inability to follow multiple levels of out-of-zone glue - - Some recursive name server implementations are unable to follow more - than one level of out-of-zone glue. For example, consider the - following delegations: - - foo.example. IN NS ns1.example.com. - foo.example. IN NS ns2.example.com. - - example.com. IN NS ns1.test.example.net. - example.com. IN NS ns2.test.example.net. - - test.example.net. IN NS ns1.test.example.net. - test.example.net. IN NS ns2.test.example.net. - - A name server processing a recursive query for "www.foo.example" must - follow two levels of indirection, first obtaining address records for - "ns1.test.example.net" and/or "ns2.test.example.net" in order to - obtain address records for "ns1.example.com" and/or "ns2.example.com" - in order to query those name servers for the address records of - "www.foo.example". While this situation may appear contrived, we - have seen multiple similar occurrences and expect more as new generic - - - -Larson & Barber Expires August 16, 2004 [Page 6] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - top-level domains (gTLDs) become active. We anticipate many zones in - the new gTLDs will use name servers in other gTLDs, increasing the - amount of inter-zone glue. - -2.3.1 Recommendation - - Clearly constructing a delegation that relies on multiple levels of - out-of-zone glue is not a good administrative practice. This issue - could be mitigated with an operational injunction in an RFC to - refrain from construction of such delegations. In our opinion the - practice is widespread enough to merit clarifications to the DNS - protocol specification to permit it on a limited basis. - - Name servers offering recursion SHOULD be able to handle at least - three levels of indirection resulting from out-of-zone glue. - -2.4 Aggressive retransmission when fetching glue - - When an authoritative name server responds with a referral, it - includes NS records in the authority section of the response. - According to the algorithm in section 4.3.2 of RFC 1034 [2], the name - server should also "put whatever addresses are available into the - additional section, using glue RRs if the addresses are not available - from authoritative data or the cache." Some name server - implementations take this address inclusion a step further with a - feature called "glue fetching". A name server that implements glue - fetching attempts to include A records for every NS record in the - authority section. If necessary, the name server issues multiple - queries of its own to obtain any missing A records. - - Problems with glue fetching can arise in the context of - "authoritative-only" name servers, which only serve authoritative - data and ignore requests for recursion. Such a server will not - generate any queries of its own. Instead it answers non-recursive - queries from resolvers looking for information in zones it serves. - With glue fetching enabled, however, an authoritative server will - generate queries whenever it needs to look up an unknown address - record to complete the additional section of a response. - - We have observed situations where a glue-fetching name server can - send queries that reach other name servers, but apparently is - prevented from receiving the responses. For example, perhaps the - name server is authoritative-only and therefore its administrators - expect it to receive only queries. Perhaps unaware of glue fetching - and presuming that the name server will generate no queries, its - administrators place the name server behind a network device that - prevents it from receiving responses. If this is the case, all - glue-fetching queries will go answered. - - - -Larson & Barber Expires August 16, 2004 [Page 7] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - We have observed name server implementations that retry excessively - when glue-fetching queries are unanswered. A single com/net name - server has received hundreds of queries per second from a single name - server. Judging from the specific queries received and based on - additional analysis, we believe these queries result from overly - aggressive glue fetching. - -2.4.1 Recommendation - - Implementers whose name servers support glue fetching should take - care to avoid sending queries at excessive rates. Implementations - should support throttling logic to detect when queries are sent but - no responses are received. - -2.5 Aggressive retransmission behind firewalls - - A common occurrence and one of the largest sources of repeated - queries at the com/net and root name servers appears to result from - resolvers behind misconfigured firewalls. In this situation, a - recursive name server is apparently allowed to send queries through a - firewall to other name servers, but not receive the responses. The - result is more queries than necessary because of retransmission, all - of which are useless because the responses are never received. Just - as with the glue-fetching scenario described in Section 2.4, the - queries are sometimes sent at excessive rates. To make matters - worse, sometimes the responses, sent in reply to legitimate queries, - trigger an alarm on the originator's intrusion detection system. We - are frequently contacted by administrators responding to such alarms - who believe our name servers are attacking their systems. - - Not only do some resolvers in this situation retransmit queries at an - excessive rate, but they continue to do so for days or even weeks. - This scenario could result from an organization with multiple - recursive name servers, only a subset of whose traffic is improperly - filtered in this manner. Stub resolvers in the organization could be - configured to query multiple name servers. Consider the case where a - stub resolver queries a filtered name server first. This name server - sends one or more queries whose replies are filtered, so it can't - respond to the stub resolver, which times out. The resolver - retransmits to a name server that is able to provide an answer. - Since resolution ultimately succeeds the underlying problem might not - be recognized or corrected. A popular stub resolver has a very - aggressive retransmission schedule, including simultaneous queries to - multiple name servers, which could explain how such a situation could - persist without being detected. - -2.5.1 Recommendation - - - - -Larson & Barber Expires August 16, 2004 [Page 8] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - The most obvious recommendation is that administrators should take - care not to place recursive name servers behind a firewall that - prohibits queries to pass through but not the resulting replies. - - Name servers should take care to avoid sending queries at excessive - rates. Implementations should support throttling logic to detect - when queries are sent but no responses are received. - -2.6 Misconfigured NS records - - Sometimes a zone administrator forgets to add the trailing dot on the - domain names in the RDATA of a zone's NS records. Consider this - fragment of the zone file for "example.com": - - $ORIGIN example.com. - example.com. 3600 IN NS ns1.example.com ; Note missing - example.com. 3600 IN NS ns2.example.com ; trailing dots - - The zone's authoritative servers will parse the NS RDATA as - "ns1.example.com.example.com" and "ns2.example.com.example.com" and - return NS records with this incorrect RDATA in responses, including - typically the authority section of every response containing records - from the "example.com" zone. - - Now consider a typical sequence of queries. A recursive name server - attempting to resolve A records for "www.example.com" with no cached - information for this zone will query a "com" authoritative server. - The "com" server responds with a referral to the "example.com" zone, - consisting of NS records with valid RDATA and associated glue - records. (This example assumes that the "example.com" zone - information is correct in the "com" zone.) The recursive name server - caches the NS RRset from the "com" server and follows the referral by - querying one of the "example.com" authoritative servers. This server - responds with the "www.example.com" A record in the answer section - and, typically, the "example.com" NS records in the authority section - and, if space in the message remains, glue A records in the - additional section. According to Section 5.4 of RFC 2181 [4], NS - records in the authority section of an authoritative answer are more - trustworthy than NS records from the authority section of a - non-authoritative answer. Thus the "example.com" NS RRset just - received from the "example.com" authoritative server displaces the - "example.com" NS RRset received moments ago from the "com" - authoritative server. - - But the "example.com" zone contains the erroneous NS RRset as shown - in the example above. Subsequent queries for names in "example.com" - will cause the server to attempt to use the incorrect NS records and - so the server will try to resolve the nonexistent names - - - -Larson & Barber Expires August 16, 2004 [Page 9] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - "ns1.example.com.example.com" and "ns2.example.com.example.com". In - this example, since all of the zone's name servers are named in the - zone itself (i.e., "ns1.example.com.example.com" and - "ns2.example.com.example.com" both end in "example.com") and all are - bogus, the recursive server cannot reach any "example.com" name - servers. Therefore attempts to resolve these names result in A - record queries to the "com' authoritative servers. Queries for such - obviously bogus glue A records occur frequently at the com/net name - servers. - -2.6.1 Recommendation - - An authoritative server can detect this situation. A trailing dot - missing from an NS record's RDATA always results by definition in a - name server name that is in the zone. But any in-zone name server - should have a corresponding glue A record also in the zone. An - authoritative name server should report an error when a zone's NS - record references an in-zone name server without a corresponding glue - A record. - -2.7 Name server records with zero TTL - - Sometimes a popular com/net subdomain's zone is configured with a TTL - of zero on the zone's NS records, which prohibits these records from - being cached and will result in a higher query volume to the zone's - authoritative servers. The zone's administrator should understand - the consequences of such a configuration and provision resources - accordingly. A zero TTL on the zone's NS RRset, however, carries - additional consequences beyond the zone itself: if a recursive name - server cannot cache a zone's NS records because of a zero TTL, it - will be forced to query that zone's parent's name servers each time - it resolves a name in the zone. The com/net authoritative servers do - see an increased query load when a popular com/net subdomain's zone - is configured with a TTL of zero on the zone's NS records. - - A zero TTL on an RRset expected to change frequently is extreme but - permissible. A zone's NS RRset is a special case, however, because - changes to it must be coordinated with the zone's parent. In most - zone parent/child relationships we are aware of, there is typically - some delay involved in effecting changes. Further, changes to the - set of a zone's authoritative name servers (and therefore to the - zone's NS RRset) are typically relatively rare: providing reliable - authoritative service requires a reasonably stable set of servers. - Therefore an extremely low or zero TTL on a zone's NS RRset rarely - makes sense, except in anticipation of an upcoming change. In this - case, when the zone's administrator has planned a change and does not - want recursive name servers throughout the Internet to cache the NS - RRset for a long period of time, a low TTL is reasonable. - - - -Larson & Barber Expires August 16, 2004 [Page 10] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -2.7.1 Recommendation - - Because of the additional load placed on a zone's parent's - authoritative servers imposed by a zero TTL on a zone's NS RRset, - under such circumstances authoritative name servers should issue a - warning when loading a zone or refuse to load the zone altogether. - -2.8 Unnecessary dynamic update messages - - The UPDATE message specified in RFC 2136 [6] allows an authorized - agent to update a zone's data on an authoritative name server using a - DNS message sent over the network. Consider the case of an agent - desiring to add a particular resource record. Because of zone cuts, - the agent does not necessarily know the proper zone to which the - record should be added. The dynamic update process requires that the - agent determine the appropriate zone so the UPDATE message can be - sent to one of the zone's authoritative servers (typically the - primary master as specified in the zone's SOA MNAME field). - - The appropriate zone to update is the closest enclosing zone, which - is the lowest zone in the name space. The closest enclosing zone - cannot be determined only by inspecting the domain name of the record - to be updated, since zone cuts can occur anywhere. One way to - determine the closest enclosing zone involves working up the name - space tree and sending repeated UPDATE messages until success. For - example, consider an agent attempting to add an A record with the - name "foo.bar.example.com". The agent could first attempt to update - the "foo.bar.example.com" zone. If the attempt failed, the update - could be directed to the "bar.example.com" zone, then the - "example.com" zone, then the "com" zone, and finally the root zone. - - A popular dynamic agent follows this algorithm. The result is many - UPDATE messages received by the root name servers, the com/net - authoritative servers, and presumably other TLD authoritative - servers. A reasonable question is why the algorithm proceeds with - sending updates all the way to TLD and root name servers. In - enterprise DNS architectures with an "internal root" design, there - could conceivably be private, non-public TLD or root zones that would - be the appropriate target for a dynamic update. However, we question - if designing an algorithm to accommodate these limited cases is worth - the load it places on the public DNS in the form of unnecessary - UPDATE messages. - -2.8.1 Recommendation - - Dynamic update agents should not attempt to send UPDATE messages to - authoritative servers for TLD zones or the root zone by default. If - this functionality is supported, it should be require specific action - - - -Larson & Barber Expires August 16, 2004 [Page 11] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - by a user to be enabled. - -2.9 Queries for domain names resembling IP addresses - - The root name servers receive a significant number of A record - queries where the qname is an IP address. The source of these - queries is unknown. It could be attributed to situations where a - user believes an application will accept either a domain name or an - IP address in a given configuration option. The user enters an IP - address, but the application assumes any input is a domain name and - attempts to resolve it, resulting in an A record lookup. There could - also be applications that produce such queries in a misguided attempt - to reverse map IP addresses. - - These queries result in Name Error (RCODE=3) responses. A recursive - name server can negatively cache such responses, but each response - requires a separate cache entry, i.e., a negative cache entry for the - domain name "192.0.2.1" does not prevent a subsequent query for the - domain name "192.0.2.2". - -2.9.1 Recommendation - - It would be desirable for the root name servers not to have to answer - these queries: they unnecessarily consume CPU resources and network - bandwidth. One possibility is for recursive name server - implementations to produce the Name Error response directly. We - suggest that implementors consider the option of synthesizing Name - Error responses at the recursive name server. The server could claim - authority for synthesized TLD zones corresponding to the first octet - of every possible IP address, e.g. 1., 2., through 255. This - behavior could be configurable in the (probably unlikely) event that - numeric TLDs are ever put into use. - - Another option is to delegate these numeric TLDs from the root zone - to a separate set of servers to absorb the traffic. The "blackhole - servers" used by the the AS 112 Project [8], which are currently - delegated the in-addr.arpa zones corresponding to RFC 1918 [7] - private use address space, would be a possible choice to receive - these delegations. - -2.10 Misdirected recursive queries - - The root name servers receive a significant number of recursive - queries (i.e., queries with the RD bit set in the header). Since - none of the root servers offer recursion, the servers' response in - such a situation ignores the request for recursion and the response - probably does not contain the data the querier anticipated. Some of - these queries result from users configuring stub resolvers to query a - - - -Larson & Barber Expires August 16, 2004 [Page 12] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - root server. (This situation is not hypothetical: we have received - complaints from users when this configuration does not work as - hoped.) Of course, users should not direct stub resolvers to use name - servers that do not offer recursion, but we are not aware of any stub - resolver implementation that offers any feedback to the user when so - configured, aside from simply "not working". - -2.10.1 Recommendation - - When the IP address of a (supposedly) recursive name server is - configured in a stub resolver using an interactive user interface, - the resolver could send a test query to verify that the server - supports recursion (i.e., the response has the RA bit set in the - header). The user could be immediately notified if the server is - non-recursive. - - The stub resolver could also report an error, either through a user - interface or in a log file, if the queried server does not support - recursion. Error reporting should be throttled to avoid a - notification or log message for every response from a non-recursive - server. - -2.11 Suboptimal name server selection algorithm - - An entire document could be devoted to the topic of problems with - different implementations of the recursive resolution algorithm. The - entire process of recursion is woefully underspecified, requiring - each implementor to design an algorithm. Sometimes implementors make - poor design choices that could be avoided if a suggested algorithm - and best practices were documented, but that is a topic for another - document. - - Some deficiencies cause significant operational impact and are - therefore worth mentioning here. One of these is name server - selection by a recursive name server. When a recursive name server - wants to contact one of a zone's authoritative name servers, how does - it choose from the NS records listed in the zone's NS RRset? If the - selection mechanism is suboptimal, queries are not spread evenly - among a zone's authoritative servers. The details of the selection - mechanism are up to the implementor, but we offer some suggestions. - -2.11.1 Recommendation - - This list is not conclusive, but reflects the changes that would - produce the most impact in terms of reducing disproportionate query - load among a zone's authoritative servers. I.e., these changes would - help spread the query load evenly. - - - - -Larson & Barber Expires August 16, 2004 [Page 13] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - o Do not make assumptions based on NS RRset order: all NS RRs should - be treated equally. (In the case of the "com" zone, for example, - most of the root servers return the NS record for - "a.gtld-servers.net" first in the authority section of referrals. - As a result, this server receives disproportionately more traffic - than the other 12 authoritative servers for "com".) - - o Use all NS records in an RRset. (For example, we are aware of - implementations that hard-coded information for a subset of the - root servers.) - - o Maintain state and favor the best-performing of a zone's - authoritative servers. A good definition of performance is - response time. Non-responsive servers can be penalized with an - extremely high response time. - - o Do not lock onto the best-performing of a zone's name servers. A - recursive name server should periodically check the performance of - all of a zone's name servers to adjust its determination of the - best-performing one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 14] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -3. IANA considerations - - There are no new IANA considerations introduced by this - Internet-Draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 15] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -4. Security considerations - - Name server and resolver misbehaviors identical or similar to those - discussed in this document expose the root and TLD name servers to - increased risk of both intentional and unintentional denial of - service. - - We believe that implementation of the recommendations offered in this - document will reduce the amount of unnecessary traffic seen at root - and TLD name servers, thus reducing the opportunity for an attacker - to use such queries to his or her advantage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 16] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -5. Internationalization considerations - - We do not believe this document introduces any new - internationalization considerations to the DNS protocol - specification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 17] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [3] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - - [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - 2308, March 1998. - - [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April - 1997. - - [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. - Lear, "Address Allocation for Private Internets", BCP 5, RFC - 1918, February 1996. - - [8] <http://www.as112.net> - - -Authors' Addresses - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - Piet Barber - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: pbarber@verisign.com - - - - - -Larson & Barber Expires August 16, 2004 [Page 18] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Larson & Barber Expires August 16, 2004 [Page 19] - -Internet-Draft Observed DNS Resolution Misbehavior February 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Larson & Barber Expires August 16, 2004 [Page 20] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt deleted file mode 100644 index 04815175fdbab..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt +++ /dev/null @@ -1,1344 +0,0 @@ -
-DNSOP O. Kolkman
-Internet-Draft RIPE NCC
-Expires: August 30, 2004 R. Gieben
- NLnet Labs
- March 2004
-
-
- DNSSEC Operational Practices
- draft-ietf-dnsop-dnssec-operational-practices-01.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 30, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document describes a set of practices for operating a DNSSEC
- aware environment. The target audience is zone administrators
- deploying DNSSEC that need a guide to help them chose appropriate
- values for DNSSEC parameters. It also discusses operational matters
- such as key rollovers, KSK and ZSK considerations and related
- matters.
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 1]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3
- 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3
- 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5
- 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7
- 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8
- 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8
- 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8
- 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8
- 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9
- 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10
- 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13
- 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14
- 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
- 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15
- 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16
- 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16
- 5.1 Initial Key Exchanges and Parental Policies
- Considerations . . . . . . . . . . . . . . . . . . . . . . 16
- 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16
- 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17
- 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
- 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
- A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19
- B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20
- C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20
- D. Document Details and Changes . . . . . . . . . . . . . . . . . 22
- D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22
- D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22
- Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 2]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-1. Introduction
-
- During workshops and early operational deployment tests, operators
- and system administrators gained experience about operating DNSSEC
- aware DNS services. This document translates these experiences into
- a set of practices for zone administrators. At the time of writing,
- there exists very little experience with DNSSEC in production
- environments, this document should therefore explicitly not be seen
- as represented 'Best Current Practices'.
-
- The procedures herein are focused on the maintenance of signed zones
- (i.e. signing and publishing zones on authoritative servers). It is
- intended that maintenance of zones such as resigning or key rollovers
- be transparent to any verifying clients on the Internet.
-
- The structure of this document is as follows: It begins with
- discussing some of the considerations with respect to timing
- parameters of DNS in relation to DNSSEC (Section 2). Aspects of key
- management such as key rollover schemes are described in Section 3.
- Emergency rollover considerations are addressed in Section 4. The
- typographic conventions used in this document are explained in
- Appendix C.
-
- Since this is a document with operational suggestions and there are
- no protocol specifications, the RFC2119 [5] language does not apply.
-
-1.1 The Use of the Term 'key'
-
- It is assumed that the reader is familiar with the concept of
- asymmetric keys on which DNSSEC is based (Public Key Cryptography
- [Ref to Schneider?]). Therefore, this document will use the term
- 'key' rather loosely. Where it is written that 'a key is used to sign
- data' it is assumed that the reader understands that it is the
- private part of the key-pair that is used for signing. It is also
- assumed that the reader understands that the public part of the
- key-pair is published in the DNSKEY resource record and that it is
- used in key-exchanges.
-
-1.2 Keeping the Chain of Trust Intact
-
- Maintaining a valid chain of trust is important because broken chains
- of trust will result in data being marked as bogus, which may cause
- entire (sub)domains to become invisible to verifying clients. The
- administrators of secured zones have to realise that their zone is,
- to their clients, part of a chain of trust.
-
- As mentioned in the introduction, the procedures herein are intended
- to ensure maintenance of zones, such as resigning or key rollovers,
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 3]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- be transparent to the verifying clients on the Internet.
- Administrators of secured zones will have to keep in mind that data
- published on an authoritative primary server will not be immediately
- seen by verifying clients; it may take some time for the data to be
- transfered to other secondary authoritative nameservers, during which
- period clients may be fetching data from caching non-authoritative
- servers. For the verifying clients it is important that data from
- secured zones can be used to build chains of trust regardless of
- whether the data came directly from an authoritative server, a
- caching nameserver or some middle box. Only by carefully using the
- available timing parameters can a zone administrator assure that the
- data necessary for verification can be obtained.
-
- The responsibility for maintaining the chain of trust is shared by
- administrators of secured zones in the chain of trust. This is most
- obvious in the case of a 'key compromise' when a trade off between
- maintaining a valid chain of trust and the fact that the key has been
- stolen, must be made.
-
- The zone administrator will have to make a tradeoff between keeping
- the chain of trust intact -thereby allowing for attacks with the
- compromised key- or to deliberately break the chain of trust thereby
- making secured subdomains invisible to security aware resolvers. Also
- see Section 4.
-
-2. Time in DNSSEC
-
- Without DNSSEC all times in DNS are relative. The SOA's refresh,
- retry and expiration timers are counters that are used to determine
- the time elapsed after a slave server syncronised (or tried to
- syncronise) with a master server. The Time to Live (TTL) value and
- the SOA minimum TTL parameter [6] are used to determine how long a
- forwarder should cache data after it has been fetched from an
- authoritative server. DNSSEC introduces the notion of an absolute
- time in the DNS. Signatures in DNSSEC have an expiration date after
- which the signature is marked as invalid and the signed data is to be
- considered bogus.
-
-2.1 Time Definitions
-
- In this document we will be using a number of time related terms.
- Within the context of this document the following definitions apply:
- o "Signature validity period"
- The period that a signature is valid. It starts at the time
- specified in the signature inception field of the RRSIG RR and
- ends at the time specified in the expiration field of the RRSIG
- RR.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 4]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- o "Signature publication period"
- Time after which a signature (made with a specific key) is
- replaced with a new signature (made with the same key). This
- replacement takes place by publishing the relevant RRSIG in the
- master zone file. If a signature is published at time T0 and a
- new signature is published at time T1, the signature
- publication period is T1 - T0.
- If all signatures are refreshed at zone (re)signing then the
- signature publication period is equal signature validity
- period.
- o "Maximum/Minimum Zone TTL"
- The maximum or minimum value of all the TTLs in a zone.
-
-2.2 Time Considerations
-
- Because of the expiration of signatures, one should consider the
- following.
- o The Maximum Zone TTL of your zone data should be a fraction of
- your signature validity period.
- If the TTL would be of similar order as the signature validity
- period, then all RRsets fetched during the validity period
- would be cached until the signature expiration time. As a
- result query load on authoritative servers would peak at
- signature expiration time.
- To avoid query load peaks we suggest the TTL on all the RRs in
- your zone to be at least a few times smaller than your
- signature validity period.
- o The signature publication period should be at least one maximum
- TTL smaller than the signature validity period.
- Resigning a zone shortly before the end of the signature
- validity period may cause simultaneous expiration of data from
- caches. This in turn may lead to peaks in the load on
- authoritative servers.
- o The Minimum zone TTL should be long enough to both fetch and
- verify all the RRs in the authentication chain.
- 1. During validation, some data may expire before the
- validation is complete. The validator should be able to keep
- all data, until is completed. This applies to all RRs needed
- to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and
- the final answers i.e. the RR that is returned for the
- initial query.
- 2. Frequent verification causes load on recursive
- nameservers. Data at delegation points, DSs, DNSKEYs and
- RRSIGs benefit from caching. The TTL on those should be
- relatively long.
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 5]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- We have seen events where data needed for verification of an
- authentication chain had expired from caches.
- We suggest the TTL on DNSKEY and DSs to be between ten minutes
- and one hour. We recommend zone administrators to chose TTLs
- longer than half a minute.
- [Editor's Note: this observation could be implementation
- specific. We are not sure if we should leave this item]
- o Slave servers will need to be able to fetch newly signed zones
- well before the data expires from your zone.
- 'Better no answers than bad answers.'
- If a properly implemented slave server is not able to contact a
- master server for an extended period the data will at some
- point expire and the slave server will not hand out any data.
- If the server serves a DNSSEC zone than it may well happen that
- the signatures expire well before the SOA expiration timer
- counts down to zero. It is not possible to completely prevent
- this from happening by tweaking the SOA parameters. However,
- the effects can be minimized where the SOA expiration time is
- equal or smaller than the signature validity period.
- The consequence of an authoritative server not being able to
- update a zone, whilst that zone includes expired signaturs, is
- that non-secure resolvers will continue to be able to resolve
- data served by the particular slave servers. Security aware
- resolvers will experience problems.
- We suggest the SOA expiration timer being approximately one
- third or one fourth of the signature validity period. It will
- allow problems with transfers from the master server to be
- noticed before the actual signature time out.
- We suggest that operators of nameservers with slave zones
- develop 'watch dogs' to spot upcoming signature expirations in
- slave zones, and take appropriate action.
- When determining the value for the expiration parameter one has
- to take the following into account: What are the chances that
- all my secondary zones expire; How quickly can I reach an
- administrator and load a valid zone? All these arguments are
- not DNSSEC specific.
-
-3. Keys
-
- In the DNSSEC protocol there is only one type of key, the zone key.
- With this key, the data in a zone is signed.
-
- To make zone re-signing and key rollovers procedures easier to
- implement, it is possible to use one or more keys as Key Signing Keys
- (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other
- keys can be used to sign all the RRsets in a zone and are referred to
- as Zone Signing Keys (ZSK). In this document we assume that KSKs are
- the subset of keys that are used for key exchanges with the parents
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 6]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- and potentially for configuration as trusted anchors - the so called
- Secure Entry Point keys (SEP). In this document we assume a
- one-to-one mapping between KSK and SEP keys and we assume the SEP
- flag [4] to be set on KSKs.
-
-3.1 Motivations for the KSK and ZSK Functions
-
- Differentiating between the KSK to ZSK functions has several
- advantages:
-
- o Making the KSK stronger (i.e. using more bits in the key material)
- has little operational impact since it is only used to sign a
- small fraction of the zone data.
- o As the KSK is only used to sign a keyset, which is most probably
- updated less frequently than other data in the zone, it can be
- stored separately from (and thus in a safer location than) the
- ZSK.
- o A KSK can be used for longer periods.
- o No parent/child interaction is required when ZSKs are updated.
-
- The KSK is used less than ZSK, once a keyset is signed with the KSK
- all the keys in the keyset can be used as ZSK. If a ZSK is
- compromised, it can be simply dropped from the keyset. The new keyset
- is then resigned with the KSK.
-
- Given the assumption that for KSKs the SEP flag is set, the KSK can
- be distinguished from a ZSK by examining the flag field in the DNSKEY
- RR. If the flag field is an odd number it is a KSK if it is an even
- number it is a ZSK e.g. a value of 256 and a key signing key has 257.
-
- The zone-signing key can be used to sign all the data in a zone on a
- regular basis. When a zone-signing key is to be rolled, no
- interaction with the parent is needed. This allows for relatively
- short "Signature Validity Periods". That is, Signature Validity
- Periods of the order of days.
-
- The key-signing key is only to be used to sign the Key RR set from
- the zone apex. If a key-signing key is to be rolled over, there will
- be interactions with parties other than the zone administrator such
- as the registry of the parent zone or administrators of verifying
- resolvers that have the particular key configured as trusted entry
- points. Hence, the "Key Usage Time" of these keys can and should be
- made much longer. Although, given a long enough key, the "Key Usage
- Time" can be on the order of years we suggest to plan for a "Key
- Usage Time" of the order of a few months so that a key rollover
- remains an operational routine.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 7]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-3.2 Key Security Considerations
-
- Keys in DNSSEC have a number of parameters which should all be chosen
- with care, the most important once are: size, algorithm and the key
- validity period (its lifetime).
-
-3.2.1 Key Validity Period
-
- RFC2541 [2] describes a number of considerations with respect to the
- security of keys. The document deals with the generation, lifetime,
- size and storage of private keys.
-
- In Section 3 of RFC2541 [2] there are some suggestions for a key
- validity period: 13 months for long-lived keys and 36 days for
- transaction keys but suggestions for key sizes are not made.
-
- If we say long-lived keys are key-signing keys and transactions keys
- are zone-signing keys, these recommendations will lead to rollovers
- occurring frequently enough to become part of 'operational habits';
- the procedure does not have to be reinvented every time a key is
- replaced.
-
-3.2.2 Key Algorithm
-
- We recommend you choose RSA/SHA-1 as the preferred algorithm for the
- key. RSA has been developed in an open and transparent manner. As the
- patent on RSA expired in 2001, its use is now also free. The current
- known attacks on RSA can be defeated by making your key longer. As
- the MD5 hashing algorithm is showing (theoretical) cracks, we
- recommend the usage of SHA1.
-
-3.2.3 Key Sizes
-
- When choosing key sizes, zone administrators will need to take into
- account how long a key will be used and how much data will be signed
- during the key publication period. It is hard to give precise
- recommendations but Lenstra and Verheul [9] supplied the following
- table with lower bound estimates for cryptographic key sizes. Their
- recommendations are based on a set of explicitly formulated parameter
- settings, combined with existing data points about cryptosystems. For
- details we refer to the original paper.
-
- [Editor's Note: DSA???]
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 8]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- Year RSA Key Sizes Elliptic Curve Key Size
- 2000 952 132
- 2001 990 135
- 2002 1028 139
- 2003 1068 140
- 2004 1108 143
-
- 2005 1149 147
- 2006 1191 148
- 2007 1235 152
- 2008 1279 155
- 2009 1323 157
-
-
- 2010 1369 160
- 2011 1416 163
- 2012 1464 165
- 2013 1513 168
- 2014 1562 172
-
- 2015 1613 173
- 2016 1664 177
- 2017 1717 180
- 2018 1771 181
- 2019 1825 185
-
-
- 2020 1881 188
- 2021 1937 190
- 2022 1995 193
- 2023 2054 197
- 2024 2113 198
-
- 2025 2174 202
- 2026 2236 205
- 2027 2299 207
- 2028 2362 210
- 2029 2427 213
-
- For example, should you wish your key to last three years from 2003,
- check the RSA keysize values for 2006 in this table. In this case
- 1191.
-
-3.3 Key Rollovers
-
- Key rollovers are a fact of life when using DNSSEC. A DNSSEC key
- cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone
- administrators who are in the process of rolling their keys have to
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 9]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- take into account that data published in previous versions of their
- zone still lives in caches. When deploying DNSSEC, this becomes an
- important consideration; ignoring data that may be in caches may lead
- to loss of service for clients.
-
- The most pressing example of this is when zone material signed with
- an old key is being validated by a resolver which does not have the
- old zone key cached. If the old key is no longer present in the
- current zone, this validation fails, marking the data bogus.
- Alternatively, an attempt could be made to validate data which is
- signed with a new key against an old key that lives in a local cache,
- also resulting in data being marked bogus.
-
- To appreciate the situation one could think of a number of
- authoritative servers that may not be instantaneously running the
- same version of a zone and a security aware non-recursive resolver
- that sits behind security aware caching forwarders.
-
- Note that KSK rollovers and ZSK rollovers are different. A zone-key
- rollover can be handled in two different ways: pre-publish (Section
- Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The
- pre-publish technique works because the key-signing key stays the
- same during this ZSK rollover. With this KSK a cache is able to
- validate the new keyset of a zone. With a KSK rollover a cache can
- not validate the new keyset, because it does not trust the new KSK.
-
- [Editors note: This needs more verbose explanation, nobody will
- appreciate the situation just yet. Help with text and examples is
- appreciated]
-
-3.3.1 Zone-signing Key Rollovers
-
- For zone-signing key rollovers there are two ways to make sure that
- during the rollover data still cached can be verified with the new
- keysets or newly generated signatures can be verified with the keys
- still in caches. One schema uses double signatures, it is described
- in Section 3.3.1.2, the other uses key pre-publication (Section
- 3.3.1.1). The pros, cons and recommendations are described in Section
- 3.3.1.3.
-
-3.3.1.1 Pre-publish Keyset Rollover
-
- This section shows how to perform a ZSK rollover without the need to
- sign all the data in a zone twice - the so called "prepublish
- rollover". We recommend this method because it has advantages in the
- case of key compromise. If the old key is compromised, the new key
- has already been distributed in the DNS. The zone administrator is
- then able to quickly switch to the new key and remove the compromised
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 10]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- key from the zone. Another major advantage is that the zone size does
- not double, as is the case with the double signature ZSK rollover. A
- small "HOWTO" for this kind of rollover can be found in Appendix B.
-
- normal pre-roll roll after
-
- SOA0 SOA1 SOA2 SOA3
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11 DNSKEY11
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
-
-
- normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
- DNSKEY 10 is used to sign all the data of the zone, the
- zone-signing key.
- pre-roll: DNSKEY 11 is introduced into the keyset. Note that no
- signatures are generated with this key yet, but this does not
- secure against brute force attacks on the public key. The minimum
- duration of this pre-roll phase is the time it takes for the data
- to propagate to the authoritative servers plus TTL value of the
- keyset. This equates to two times the Maximum Zone TTL.
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign
- the data in the zone exclusively (i.e. all the signatures from
- DNSKEY 10 are removed from the zone). DNSKEY 10 remains published
- in the keyset. This way data that was loaded into caches from
- version 1 of the zone can still be verified with key sets fetched
- from version 2 of the zone.
- The minimum time that the keyset including DNSKEY 10 is to be
- published is the time that it takes for zone data from the
- previous version of the zone to expire from old caches i.e. the
- time it takes for this zone to propagate to all authoritative
- servers plus the Maximum Zone TTL value of any of the data in the
- previous version of the zone.
- after: DNSKEY 10 is removed from the zone. The keyset, now only
- containing DNSKEY 11 is resigned with the DNSKEY 1.
-
- The above scheme can be simplified by always publishing the "future"
- key immediately after the rollover. The scheme would look as follows
- (we show two rollovers); the future key is introduced in "after" as
- DNSKEY 12 and again a newer one, numbered 13, in "2nd after":
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 11]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- normal roll after 2nd roll 2nd after
-
- SOA0 SOA2 SOA3 SOA4 SOA5
- RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5)
-
- DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12
- DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13
- RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY)
-
-
- Note that the key introduced after the rollover is not used for
- production yet; the private key can thus be stored in a physically
- secure manner and does not need to be 'fetched' every time a zone
- needs to be signed.
-
- This scheme has the benefit that the key that is intended for future
- use: immediately during an emergency rollover assuming that the
- private key was stored in a physically secure manner.
-
-3.3.1.2 Double Signature Zone-signing Key Rollover
-
- This section shows how to perform a ZSK key rollover using the double
- zone data signature scheme, aptly named "double sig rollover".
-
- During the rollover stage the new version of the zone file will need
- to propagate to all authoritative servers and the data that exists in
- (distant) caches will need to expire, this will take at least the
- maximum Zone TTL .
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
- RRSIG11(SOA1)
-
- DNSKEY1 DNSKEY1 DNSKEY1
- DNSKEY10 DNSKEY10 DNSKEY11
- DNSKEY11
- RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
- RRSIG11(DNSKEY)
-
- normal: Version 0 of the zone: DNSKEY 1 is the key-signing key.
- DNSKEY 10 is used to sign all the data of the zone, the
- zone-signing key.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 12]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced
- into the keyset and all the data in the zone is signed with DNSKEY
- 10 and DNSKEY 11. The rollover period will need to exist until all
- data from version 0 of the zone has expired from remote caches.
- This will take at least the maximum Zone TTL of version 0 of the
- zone.
- after: DNSKEY 10 is removed from the zone. All the signatures from
- DNSKEY 10 are removed from the zone. The keyset, now only
- containing DNSKEY 11, is resigned with DNSKEY 1.
-
- At every instance the data from the previous version of the zone can
- be verified with the key from the current version and vice verse. The
- data from the current version can be verified with the data from the
- previous version of the zone. The duration of the rollover phase and
- the period between rollovers should be at least the "Maximum Zone
- TTL".
-
- Making sure that the rollover phase lasts until the signature
- expiration time of the data in version 0 of the zone is recommended.
- However, this date could be considerably longer than the Maximum Zone
- TTL, making the rollover a lengthy procedure.
-
- Note that in this example we assumed that the zone was not modified
- during the rollover. New data can be introduced in the zone as long
- as it is signed with both keys.
-
-3.3.1.3 Pros and Cons of the Schemes
-
- Prepublish-keyset rollover: This rollover does not involve signing
- the zone data twice. Instead, just before the actual rollover, the
- new key is published in the keyset and thus available for
- cryptanalysis attacks. A small disavantage is that this process
- requires four steps. Also the prepublish scheme will not work for
- KSKs as explained in Section 3.3.
- Double signature rollover: The drawback of this signing scheme is
- that during the rollover the number of signatures in your zone
- doubles, this may be prohibitive if you have very big zones. An
- advantage is that it only requires three steps.
-
-3.3.2 Key-signing Key Rollovers
-
- For the rollover of a key-signing key the same considerations as for
- the rollover of a zone-signing key apply. However we can use a double
- signature scheme to guarantee that old data (only the apex keyset) in
- caches can be verified with a new keyset and vice versa.
-
- Since only the keyset is signed with a KSK, zone size considerations
- do not apply.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 13]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- normal roll after
-
- SOA0 SOA1 SOA2
- RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2)
-
- DNSKEY1 DNSKEY1 DNSKEY2
- DNSKEY2
- DNSKEY10 DNSKEY10 DNSKEY10
- RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY)
- RRSIG2 (DNSKEY)
- RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
- normal: Version 0 of the zone. The parental DS points to DNSKEY1.
- Before the rollover starts the child will have to verify what the
- TTL is of the DS RR that points to DNSKEY1 - it is needed during
- the rollover and we refer to the value as TTL_DS.
- roll: During the rollover phase the zone administrator generates a
- second KSK, DNSKEY2. The key is provided to the parent and the
- child will have to wait until a new DS RR has been generated that
- points to DNSKEY2. After that DS RR has been published on _all_
- servers authoritative for the parents zone, the zone administrator
- has to wait at least TTL_DS to make sure that the old DS RR has
- expired from distant caches.
- after: DNSKEY1 has been removed.
-
- The scenario above puts the responsibility for maintaining a valid
- chain of trust with the child. It also is based on the premises that
- the parent only has one DS RR (per algorithm) per zone. St John [The
- draft has expired] proposed a mechanism where using an established
- trust relation, the interaction can be performed in-band. In this
- mechanism there are periods where there are two DS RRs at the parent.
-
- [Editors note: We probably need to mention more]
-
-4. Planning for Emergency Key Rollover
-
- This section deals with preparation for a possible key compromise.
- Our advice is to have a documented procedure ready for when a key
- compromise is suspected or confirmed.
-
- [Editors note: We are much in favor of a rollover tactic that keeps
- the authentication chain intact as long as possible. This means that
- one has to take all the regular rollover properties into account.]
-
- When the private material of one of your keys is compromised it can
- be used for as long as a valid authentication chain exists. An
- authentication chain remains intact for:
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 14]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- o as long as a signature over the compromised key in the
- authentication chain is valid,
- o as long as a parental DS RR (and signature) points to the
- compromised key,
- o as long as the key is anchored in a resolver and is used as a
- starting point for validation. (This is the hardest to update.)
- While an authentication chain to your compromised key exists, your
- name-space is vulnerable to abuse by the malicious key holder (i.e.
- the owner of the compromised key). Zone operators have to make a
- trade off if the abuse of the compromised key is worse than having
- data in caches that cannot be validated. If the zone operator chooses
- to break the authentication chain to the compromised key, data in
- caches signed with this key cannot be validated. However, if the zone
- administrator chooses to take the path of a regular roll-over, the
- malicious key holder can spoof data so that it appears to be valid,
- note that this kind of attack will usually be localised in the
- Internet topology.
-
-
-4.1 KSK Compromise
-
- When the KSK has been compromised the parent must be notified as soon
- as possible using secure means. The keyset of the zone should be
- resigned as soon as possible. Care must be taken to not break the
- authentication chain. The local zone can only be resigned with the
- new KSK after the parent's zone has been updated with the new KSK.
- Before this update takes place it would be best to drop the security
- status of a zone all together: the parent removes the DS of the child
- at the next zone update. After that the child can be made secure
- again.
-
- An additional danger of a key compromise is that the compromised key
- can be used to facilitate a legitimate DNSKEY/DS and/or nameserver
- rollover at the parent. When that happens the domain can be in
- dispute. An out of band and secure notify mechanism to contact a
- parent is needed in this case.
-
-4.2 ZSK Compromise
-
- Primarily because there is no parental interaction required when a
- ZSK is compromised, the situation is less severe than with with a KSK
- compromise. The zone must still be resigned with a new ZSK as soon
- as possible. As this is a local operation and requires no
- communication between the parent and child this can be achieved
- fairly quickly. However, one has to take into account that just as
- with a normal rollover the immediate disappearance from the old
- compromised key may lead to verification problems. The
- pre-publication scheme as discussed above minimises such problems.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 15]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-4.3 Compromises of Keys Anchored in Resolvers
-
- A key can also be pre-configured in resolvers. If DNSSEC is rolled
- out as planned the root key should be pre-configured in every secure
- aware resolver on the planet. [Editors Note: add more about
- authentication of a newly received resolver key]
-
- If trust-anchor keys are compromised, the resolvers using these keys
- should be notified of this fact. Zone administrators may consider
- setting up a mailing list to communicate the fact that a SEP key is
- about to be rolled over. This communication will of course need to be
- authenticated e.g. by using digital signatures.
-
-5. Parental Policies
-
-5.1 Initial Key Exchanges and Parental Policies Considerations
-
- The initial key exchange is always subject to the policies set by the
- parent (or its registry). When designing a key exchange policy one
- should take into account that the authentication and authorisation
- mechanisms used during a key exchange should be as strong as the
- authentication and authorisation mechanisms used for the exchange of
- delegation information between parent and child.
-
- Using the DNS itself as the source for the actual DNSKEY material,
- with an off-band check on the validity of the DNSKEY, has the benefit
- that it reduces the chances of user error. A parental DNSKEY download
- tool can make use of the SEP bit [4] to select the proper key from a
- DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is
- sent. It can validate the self-signature over a key; thereby
- verifying the ownership of the private key material. Fetching the
- DNSKEY from the DNS ensures that the child will not become bogus once
- the parent publishes the DS RR indicating the child is secure.
-
- Note: the off-band verification is still needed when the key-material
- is fetched by a tool. The parent can not be sure whether the DNSKEY
- RRs have been spoofed.
-
-5.2 Storing Keys So Hashes Can Be Regenerated
-
- When designing a registry system one should consider if the DNSKEYs
- and/or the corresponding DSs are stored. Storing DNSKEYs will help
- during troubleshooting while the overhead of calculating DS records
- from them is minimal.
-
- Having an out-of-band mechanism, such as a Whois database, to find
- out which keys are used to generate DS Resource Records for specific
- owners may also help with troubleshooting.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 16]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-5.3 Security Lameness Checks
-
- Security Lameness is defined as what happens when a parent has a DS
- Resource Record pointing to a non-existing DNSKEY RR. During key
- exchange a parent should make sure that the child's key is actually
- configured in the DNS before publishing a DS RR in its zone. Failure
- to do so would render the child's zone being marked as bogus.
-
- Child zones should be very careful removing DNSKEY material,
- specifically SEP keys, for which a DS RR exists.
-
- Once a zone is "security lame" a fix (e.g. by removing a DS RR) will
- take time to propagate through the DNS.
-
-5.4 DS Signature Validity Period
-
- Since the DS can be replayed as long as it has a valid signature a
- short signature validity period over the DS minimises the time a
- child is vulnerable in the case of a compromise of the child's
- KSK(s). A signature validity period that is too short introduces the
- possibility that a zone is marked bogus in case of a configuration
- error in the signer; there may not be enough time to fix the problems
- before signatures expire. Something as mundane as operator
- unavailability during weekends shows the need for DS signature
- lifetimes longer than 2 days. We recommend the minimum for a DS
- signature validity period to be a few days.
-
- The maximum signature lifetime of the DS record depends on how long
- child zones are willing to be vulnerable after a key compromise. We
- consider a signature validity period of around one week to be a good
- compromise between the operational constraints of the parent and
- minimising damage for the child.
-
-6. Security Considerations
-
- DNSSEC adds data integrity to the DNS. This document tries to assess
- considerations to operate a stable and secure DNSSEC service. Not
- taking into account the 'data propagation' properties in the DNS will
- cause validation failures and may make secured zones unavailable to
- security aware resolvers.
-
-7. Acknowledgments
-
- We, the folk mentioned as authors, only acted as editors. Most of the
- ideas in this draft were the result of collective efforts during
- workshops, discussions and try outs.
-
- At the risk of forgetting individuals who where the original
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 17]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- contributors of the ideas we would like to acknowledge people who
- where actively involved in the compilation of this document. In
- random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson,
- Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier
- Courtay, Sam Weiler.
-
- Emma Bretherick and Adrian Bedford corrected many of the spelling and
- style issues.
-
- Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-8. References
-
-8.1 Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key
- (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work
- in progress), February 2003.
-
-8.2 Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
- 2308, March 1998.
-
- [7] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-13 (work in progress), March
- 2003.
-
- [8] Arends, R., "Protocol Modifications for the DNS Security
- Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in
- progress), March 2003.
-
- [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes",
- The Journal of Cryptology 14 (255-293), 2001.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 18]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- The Netherlands
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Miek Gieben
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098 VA
- The Netherlands
-
- EMail: miek@nlnetlabs.nl
- URI: http://www.nlnetlabs.nl
-
-Appendix A. Terminology
-
- In this document there is some jargon used that is defined in other
- documents. In most cases we have not copied the text from the
- documents defining the terms but given a more elaborate explanation
- of the meaning. Note that these explanations should not be seen as
- authoritative.
-
- Private and Public Keys: DNSSEC secures the DNS through the use of
- public key cryptography. Public key cryptography is based on the
- existence of two keys, a public key and a private key. The public
- keys are published in the DNS by use of the DNSKEY Resource Record
- (DNSKEY RR). Private keys should remain private i.e. should not be
- exposed to parties not-authorised to do the actual signing.
- Signer: The system that has access to the private key material and
- signs the Resource Record sets in a zone. A signer may be
- configured to sign only parts of the zone e.g. only those RRsets
- for which existing signatures are about to expire.
- KSK: A Key-Signing Key (KSK) is a key that is used exclusively for
- signing the apex keyset. The fact that a key is a KSK is only
- relevant to the signing tool.
- ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all
- data in a zone. The fact that a key is a ZSK is only relevant to
- the signing tool.
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 19]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- SEP Key: A KSK that has a parental DS record pointing to it. Note:
- this is not enforced in the protocol. A SEP Key with no parental
- DS is security lame.
- Anchored Key: A DNSKEY configured in resolvers around the globe. This
- Key is hard to update, hence the term anchored.
- Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked
- "Bogus" when a signature of a RRset does not validate against the
- DNSKEY. Even if the key itself was not marked Bogus. A cache may
- choose to cache Bogus data for various reasons.
- Singing the Zone File: The term used for the event where an
- administrator joyfully signs its zone file while producing melodic
- sound patterns.
- Zone Administrator: The 'role' that is responsible for signing a zone
- and publishing it on the primary authoritative server.
-
-Appendix B. Zone-signing Key Rollover Howto
-
- Using the pre-published signature scheme and the most conservative
- method to assure oneself that data does not live in distant caches
- here follows the "HOWTO". [WES: has some comments about this]
- Key notation:
- Step 0: The preparation: Create two keys and publish both in your
- keyset. Mark one of the keys as "active" and the other as
- "published". Use the "active" key for signing your zone data.
- Store the private part of the "published" key, preferably
- off-line.
- Step 1: Determine expiration: At the beginning of the rollover make a
- note of the highest expiration time of signatures in your zone
- file created with the current key marked as "active".
- Wait until the expiration time marked in Step 1 has passed
- Step 2: Then start using the key that was marked as "published" to
- sign your data i.e. mark it as "active". Stop using the key that
- was marked as "active", mark it as "rolled".
- Step 3: It is safe to engage in a new rollover (Step 1) after at
- least one "signature validity period".
-
-Appendix C. Typographic Conventions
-
- The following typographic conventions are used in this document:
- Key notation: A key is denoted by KEYx, where x is a number, x could
- be thought of as the key id.
- RRset notations: RRs are only denoted by the type. All other
- information - owner, class, rdata and TTL - is left out. Thus:
- example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a
- list of RRs. A example of this would be: A1,A2, specifying the
- RRset containing two A records. This could again be abbreviated to
- just: A.
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 20]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- Signature notation: Signatures are denoted as RRSIGx(RRset), which
- means that RRset is signed with DNSKEYx.
- Zone representation: Using the above notation we have simplified the
- representation of a signed zone by leaving out all unnecessary
- details such as the names and by representing all data by "SOAx"
- SOA representation: SOA's are represented as SOAx, where x is the
- serial number.
- Using this notation the following zone :
-
-
- example.net. 600 IN SOA ns.example.net. ernie.example.net. (
- 10 ; serial
- 450 ; refresh (7 minutes 30 seconds)
- 600 ; retry (10 minutes)
- 345600 ; expire (4 days)
- 300 ; minimum (5 minutes)
- )
- 600 RRSIG SOA 5 2 600 20130522213204 (
- 20130422213204 14 example.net.
- cmL62SI6iAX46xGNQAdQ... )
- 600 NS a.iana-servers.net.
- 600 NS b.iana-servers.net.
- 600 RRSIG NS 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- SO5epiJei19AjXoUpFnQ ... )
- 3600 DNSKEY 256 3 5 (
- EtRB9MP5/AvOuVO0I8XDxy0...
- ) ; key id = 14
- 3600 DNSKEY 256 3 5 (
- gsPW/Yy19GzYIY+Gnr8HABU...
- ) ; key id = 15
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 14 example.net.
- J4zCe8QX4tXVGjV4e1r9... )
- 3600 RRSIG DNSKEY 5 2 3600 20130522213204 (
- 20130422213204 15 example.net.
- keVDCOpsSeDReyV6O... )
- 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC
- 600 RRSIG NSEC 5 2 600 20130507213204 (
- 20130407213204 14 example.net.
- obj3HEp1GjnmhRjX... )
- a.example.net. 600 IN TXT "A label"
- 600 RRSIG TXT 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
- IkDMlRdYLmXH7QJnuF3v... )
- 600 NSEC b.example.com. TXT RRSIG NSEC
- 600 RRSIG NSEC 5 3 600 20130507213204 (
- 20130407213204 14 example.net.
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 21]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- bZMjoZ3bHjnEz0nIsPMM... )
-
- ...
-
-
- is reduced to the following represenation:
-
- SOA10
- RRSIG14(SOA10)
-
- DNSKEY14
- DNSKEY15
-
- RRSIG14(KEY)
- RRSIG15(KEY)
-
- The rest of the zone data has the same signature as the SOA record,
- i.e a RRSIG created with DNSKEY 14.
-
-Appendix D. Document Details and Changes
-
- This section is to be removed by the RFC editor if and when the
- document is published.
-
- $Header: /var/cvs/dnssec-key/
- draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12
- 08:29:11 dnssec Exp $
-
-D.1 draft-ietf-dnsop-dnssec-operational-practices-00
-
- Submission as working group document. This document is a modified and
- updated version of draft-kolkman-dnssec-operational-practices-00.
-
-D.2 draft-ietf-dnsop-dnssec-operational-practices-01
-
- changed the definition of "Bogus" to reflect the one in the protocol
- draft.
-
- Bad to Bogus
-
- Style and spelling corrections
-
- KSK - SEP mapping made explicit.
-
- Updates from Sam Weiler added
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 22]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 23]
-
-Internet-Draft DNSSEC Operational Practices March 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben Expires August 30, 2004 [Page 24]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt deleted file mode 100644 index 42c3c0b7c7e39..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-02.txt +++ /dev/null @@ -1,1321 +0,0 @@ - -DNS Operations WG -Internet-Draft J. Jeong (ed.) - ETRI - -Expires: January 2005 18 July 2004 - - - IPv6 Host Configuration of DNS Server Information Approaches - draft-ietf-dnsop-ipv6-dns-configuration-02.txt - - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which we become aware will be disclosed, in accordance - with RFC3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet-Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 17, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document describes three approaches for IPv6 recursive DNS - server address configuration. It details the operational - attributes of three solutions: RA option, DHCPv6 option, and Well- - known anycast addresses for recursive DNS servers. Additionally, - it suggests four deployment scenarios considering multi-solution - resolution. Therefore, this document will give the audience a - - - -Jeong, et al. Expires - January 2005 [Page 1] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - guideline of IPv6 DNS configuration to select approaches suitable - for their host DNS configuration. - -Table of Contents - - 1. Introduction...................................................3 - 2. Terminology....................................................3 - 3. IPv6 DNS Configuration Approaches..............................3 - 3.1 RA Option..................................................3 - 3.1.1 Advantages...........................................4 - 3.1.2 Disadvantages........................................5 - 3.1.3 Observations.........................................5 - 3.2 DHCPv6 Option..............................................6 - 3.2.1 Advantages...........................................7 - 3.2.2 Disadvantages........................................8 - 3.2.3 Observations.........................................9 - 3.3 Well-known Anycast Addresses...............................9 - 3.3.1 Advantages...........................................9 - 3.3.2 Disadvantages.......................................10 - 3.3.3 Observations........................................10 - 4. Interworking among IPv6 DNS Configuration Approaches..........11 - 5. Deployment Scenarios..........................................12 - 5.1 ISP Network...............................................12 - 5.1.1 RA Option Approach..................................12 - 5.1.2 DHCPv6 Option Approach..............................13 - 5.1.3 Well-known Addresses Approach.......................13 - 5.2 Enterprise Network........................................14 - 5.3 3GPP Network..............................................14 - 5.3.1 Currently Available Mechanisms and Recommendations..15 - 5.3.2 RA Extension........................................16 - 5.3.3 Stateless DHCPv6....................................16 - 5.3.4 Well-known Addresses................................17 - 5.3.5 Recommendations.....................................17 - 5.4 Unmanaged Network.........................................18 - 5.4.1 Case A: Gateway does not provide IPv6 at all........18 - 5.4.2 Case B: A dual-stack gateway connected to a dual-stack - ISP.........................................18 - 5.4.3 Case C: A dual-stack gateway connected to an IPv4-only - ISP.........................................19 - 5.4.4 Case D: A gateway connected to an IPv6-only ISP.....19 - 6. Security Considerations.......................................19 - 7. Acknowledgements..............................................19 - 8. Normative References..........................................20 - 9. Informative References........................................20 - 10. Authors' Addresses...........................................21 - Intellectual Property Statement..................................23 - Full Copyright Statement.........................................23 - Acknowledgement..................................................24 - - -Jeong, et al. Expires - January 2005 [Page 2] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - -1. Introduction - - Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address - Autoconfiguration provide ways to configure either fixed or mobile - nodes with one or more IPv6 addresses, default routes and some - other parameters [3][4]. To support access to additional services - in the Internet that are identified by a DNS name, such as a web - server, the configuration of at least one recursive DNS server is - also needed for DNS name resolution. - - This document describes three approaches of recursive DNS server - address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6 - option [5]-[7], and (c) Well-known anycast addresses for recursive - DNS servers [9]. Also, it suggests applicable scenarios for four - kinds of networks: (a) ISP network, (b) Enterprise network, (c) - 3GPP network, and (d) Unmanaged network. - - This document is just an analysis of each possible approach, and - does not make any recommendation on particular one or on a - combination of particular ones. Some approaches may even not be - adopted at all as a result of further discussion. - - Therefore, the objective of this document is to help the audience - select approaches suitable for IPv6 host configuration of recursive - DNS server. - -2. Terminology - - This document uses the terminology described in [3]-[9]. In - addition, a new term is defined below: - - Recursive DNS Server (RDNSS) A Recursive DNS Server is a name - server that offers the recursive - service of DNS name resolution. - -3. IPv6 DNS Configuration Approaches - - In this section, the operational attributes of three solutions are - described in detail. - -3.1 RA Option - - RA approach is to define a new ND option called RDNSS option that - contains a recursive DNS server address. Existing ND transport - mechanisms (i.e., advertisements and solicitations) are used. This - works in the same way that nodes learn about routers and prefixes, - etc. An IPv6 host can configure the IPv6 addresses of one or more - - -Jeong, et al. Expires - January 2005 [Page 3] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - RDNSSes via RA message periodically sent by router or solicited by - a Router Solicitation (RS) [8]. This approach needs RDNSS - information to be configured in the routers doing the - advertisements. The configuration of RDNSS address can be - performed manually by operator or other ways, such as automatic - configuration through DHCPv6 client running on the router. When - advertising more than one RDNSS options, an RA message includes as - many RDNSS options as RDNSSes. Through ND protocol and RDNSS - option along with prefix information option, an IPv6 host can - perform its network configuration of its IPv6 address and RDNSS - simultaneously [3][4]. The RA option for RDNSS can be used on any - network that supports the use of ND. However, RA approach performs - poorly in some wireless environments where RA message is used for - IPv6 address autoconfiguration, such as WLAN networks. - - The RA approach is useful in some non-WLAN mobile environments - where the addresses of the RDNSSes are changing because the RA - option includes a lifetime field. This can be configured to a - value that will require the client to time out the entry and switch - over to another RDNSS address [8]. However, from the viewpoint of - implementation, lifetime would seem to make matters a bit more - complex. Instead of just writing DNS configuration file, such as - resolv.conf for the list of RDNSS addresses, we have to have a - daemon around (or a program that is called at the defined - intervals) that keeps monitoring the lifetime of RDNSSes all the - time. - - The preference value of RDNSS, included in RDNSS option, allows - IPv6 hosts to select primary RDNSS among several RDNSSes; this can - be used for load balancing of RDNSSes [8]. - -3.1.1 Advantages - - The RA option for RDNSS has a number of advantages. These include: - - 1) The RA option is an extension of existing ND/Autoconfig - mechanisms [3][4], and does not require a change in the base ND - protocol. - - 2) This approach, like ND, works well on a variety of link types - including point-to-point links, point-to-multipoint, and multi- - point (i.e., Ethernet LANs), etc. RFC2461 [3] states, however, - that there may be some link type on which ND is not possible; on - such a link, some other mechanism will be needed for DNS - configuration. - - 3) All of the information a host needs to run basic Internet - applications such as email, the web, ftp, etc., can be performed - - -Jeong, et al. Expires - January 2005 [Page 4] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - with the addition of this option to ND and address auto- - configuration. The use of a single mechanism is more reliable and - easier to provide than when the RDNSS information is learned via - another protocol mechanism. Debugging problems when multiple - protocol mechanisms are being used is harder and much more complex. - - 4) This mechanism works over a broad range of scenarios and - leverages IPv6 ND. This works well on links that support broadcast - reliably (e.g., Ethernet LANs) but not necessarily on other links - (e.g., Wireless LANs). Also, this works well on links that are - high performance (e.g., Ethernet LANs) and low performance (e.g., - Cellular networks). In the latter case, combining the RDNSS - information with the other information in the RA, the host can - learn all of the information needed to use most Internet - applications such as the web in a single packet. This not only - saves bandwidth where this is an issue, but also minimizes the - delay to learn the RDNSS information. - - 5) The RA approach could be used as a model for other similar types - of configuration information. New RA options for other server - addresses that are common to all clients on a subnet would be easy - to define. This includes things like NTP servers, SIP servers, etc. - -3.1.2 Disadvantages - - 1) ND is mostly implemented in kernel part of operating system. - Therefore, if ND supports the configuration of some additional - services, such as DNS, NTP and SIP servers, ND should be extended - in kernel part. DHCPv6, however, has more flexibility for - extension of service discovery because it is an application layer - protocol. - - 2) The current ND framework should be modified due to the - synchronization between another ND cache for RDNSSes in kernel - space and DNS configuration file in user space. Because it is - unacceptable to write and rewrite the DNS configuration file (e.g., - resolv.conf) from the kernel, another approach is needed. One - simple approach to solve this is to have a daemon listening to what - the kernel conveys, and to have the daemon do these steps, but such - a daemon is not necessary with the current ND framework. - - 3) It is necessary to configure RDNSS addresses at least at one - router on every link where this information needs to be configured - by RA option. - -3.1.3 Observations - - - - -Jeong, et al. Expires - January 2005 [Page 5] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The proposed RDNSS RA option along with IPv6 ND and Auto- - configuration allows a host to obtain all of the information it - needs to access basic Internet services like the web, email, ftp, - etc. This is preferable in environments where hosts use RAs to - autoconfigure their addresses and all hosts on the subnet share the - same router and server addresses. If the configuration information - can be obtained from a single mechanism, it is preferable because - it does not add additional delay, and it uses a minimum of - bandwidth. Environments like this include homes, public cellular - networks, and enterprise environments where no per host - configuration is needed, but exclude public WLAN hot spots. - - DHCPv6 is preferable where it is being used for address - configuration and if there is a need for host specific - configuration [5]-[7]. Environments like this are most likely - enterprise environments where the local administration chooses to - have per host configuration control. - - Note: the observation section is based on what the proponents of - each approach think makes a good overall solution. - -3.2 DHCPv6 Option - - DHCPv6 [5] includes the "DNS Recursive Name Server" option, through - which a host can obtain a list of IP addresses of recursive DNS - servers [7]. The DNS Recursive Name Server option carries a list - of IPv6 addresses of RDNSSes to which the host may send DNS queries. - The DNS servers are listed in the order of preference for use by - the DNS resolver on the host. - - The DNS Recursive Name Server option can be carried in any DHCPv6 - Reply message, in response to either a Request or an Information- - request message. Thus, the DNS Recursive Name Server option can be - used either when DHCPv6 is used for address assignment, or when - DHCPv6 is used only for other configuration information as - stateless DHCPv6 [6]. - - Stateless DHCPv6 can be deployed either using DHCPv6 servers - running on general-purpose computers, or on router hardware. - Several router vendors currently implement stateless DHCPv6 servers. - Deploying stateless DHCPv6 in routers has the advantage that no - special hardware is required, and should work well for networks - where DHCPv6 is needed for very straightforward configuration of - network devices. - - However, routers can also act as DHCPv6 relay agents. In this case, - the DHCPv6 server need not be on the router - it can be on a - general purpose computer. This has the potential to give the - - -Jeong, et al. Expires - January 2005 [Page 6] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - operator of the DHCPv6 server more flexibility in how the DHCPv6 - server responds to individual clients - clients can easily be given - different configuration information based on their identity, or for - any other reason. Nothing precludes adding this flexibility to a - router, but generally in current practice, DHCP servers running on - general-purpose hosts tend to have more configuration options than - those that are embedded in routers. - - DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 - clients that use stateful configuration assignment. To do this, - the DHCPv6 server sends a Reconfigure message to the client. The - client validates the Reconfigure message, and then contacts the - DHCPv6 server to obtain updated configuration information. Using - this mechanism, it is currently possible to propagate new - configuration information to DHCPv6 clients as this information - changes. - - The DHC Working Group is currently studying an additional mechanism - through which configuration information, including the list of - RDNSSes, can be updated. The Lifetime Option for DHCPv6 [10], - assigns a lifetime to configuration information obtained through - DHCPv6. At the expiration of the lifetime, the host contacts the - DHCPv6 server to obtain updated configuration information, - including the list of RDNSSes. This lifetime gives the network - administrator another mechanism to configure hosts with new RDNSSes - by controlling the time at which the host refreshes the list. - - The DHC Working Group has also discussed the possibility of - defining an extension to DHCPv6 that would allow the use of - multicast to provide configuration information to multiple hosts - with a single DHCPv6 message. Because of the lack of deployment - experience, the WG has deferred consideration of multicast DHCPv6 - configuration at this time. Experience with DHCPv4 has not - identified a requirement for multicast message delivery, even in - large service provider networks with tens of thousands of hosts - that may initiate a DHCPv4 message exchange simultaneously. - -3.2.1 Advantages - - The DHCPv6 option for RDNSS has a number of advantages. These - include: - - 1) DHCPv6 currently provides a general mechanism for conveying - network configuration information to clients. So configuring - DHCPv6 servers allows the network administrator to configure - RDNSSes along with the addresses of other network services, as well - as location-specific information like time zones. - - - -Jeong, et al. Expires - January 2005 [Page 7] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - 2) As a consequence, when the network administrator goes to - configure DHCPv6, all the configuration information can be managed - through a single service, typically with a single user interface - and a single configuration database. - - 3) DHCPv6 allows for the configuration of a host with information - specific to that host, so that hosts on the same link can be - configured with different RDNSSes as well as other configuration - information. This capability is important in some network - deployments such as service provider networks or WiFi hot spots. - - 4) A mechanism exists for extending DHCPv6 to support the - transmission of additional configuration that has not yet been - anticipated. - - 5) Hosts that require other configuration information such as the - addresses of SIP servers and NTP servers are likely to need DHCPv6 - for other configuration information. - - 6) The specification for configuration of RDNSSes through DHCPv6 is - available as an RFC. No new protocol extensions such as new - options are necessary. - - 7) Interoperability among independent implementations has been - demonstrated. - -3.2.2 Disadvantages - - The DHCPv6 option for RDNSS has a few disadvantages. These - include: - - 1) Update currently requires message from server (however, see - [10]). - - 2) Because DNS information is not contained in RA message, the host - must receive two messages from the router, and must transmit at - least one message to the router. On networks where bandwidth is at - a premium, this is a disadvantage, although on most networks it is - not a practical concern. - - 3) Increased latency for initial configuration - in addition to - waiting for an RA message, the client must now exchange packets - with a DHCPv6 server; even if it is locally installed on a router, - this will slightly extend the time required to configure the client. - For clients that are moving rapidly from one network to another, - this will be a disadvantage. - - - - -Jeong, et al. Expires - January 2005 [Page 8] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - -3.2.3 Observations - - In the general case, on general-purpose networks, stateless DHCPv6 - provides significant advantages and no significant disadvantages. - Even in the case where bandwidth is at a premium and low latency is - desired, if hosts require other configuration information in - addition to a list of RDNSSes or if hosts must be configured - selectively, those hosts will use DHCPv6 and the use of the DHCPv6 - DNS recursive name server option will be advantageous. - - However, we are aware of some applications where it would be - preferable to put the RDNSS information into an RA packet; for - example, on a cell phone network, where bandwidth is at a premium - and extremely low latency is desired. The final DNS configuration - draft should be written so as to allow these special applications - to be handled using DNS information in the RA packet. - -3.3 Well-known Anycast Addresses - - First of all, the well-known anycast addresses approach is much - different from that discussed in IPv6 Working Group in the past. - - The approach with well-known anycast addresses is to set well-known - anycast addresses in clients' resolver configuration files from the - beginning, say, as factory default. Thus, there is no transport - mechanism and no packet format [9]. - - An anycast address is an address shared by multiple servers (in - this case, the servers are RDNSSes). Request from a client to the - anycast address is routed to a server selected by the routing - system. However, it is a bad idea to mandate "site" boundary on - anycast addresses, because most users just do not have their own - servers and want to access their ISPs' across their site boundaries. - Larger sites may also depend on their ISPs or may have their own - RDNSSes within "site" boundaries. - - It should be noted that "anycast" in this memo is simpler than that - of RFC1546 [11] and RFC3513 [12] where it is assumed to be - prohibited to have multiple servers on a single link sharing an - anycast address. That is, on a link, anycast address is assumed to - be unique. DNS clients today already have redundancy by having - multiple well-known anycast addresses configured as RDNSS addresses. - There is no point to have multiple RDNSSes sharing an anycast - address on a single link. - -3.3.1 Advantages - - - - -Jeong, et al. Expires - January 2005 [Page 9] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The basic advantage of the well-known addresses approach is that it - uses no transport mechanism. Thus, - 1) There is no delay to get response and no further delay by packet - losses. - - 2) The approach can be combined with any other configuration - mechanisms including but not limited to factory default - configuration, RA-based approach and DHCP based approach. - - 3) The approach works over any environment where DNS works. - - Another advantage is that the approach needs to configure DNS - servers as a router, but nothing else. Considering that DNS - servers do need configuration, the amount of overall configuration - effort is proportional to the number of the DNS servers and scales - linearly. It should be noted that, in the simplest case where a - subscriber to an ISP does not have any DNS server, the subscriber - naturally access DNS servers of the ISP even though the subscriber - and the ISP do nothing and there is no protocol to exchange DNS - server information between the subscriber and the ISP. - -3.3.2 Disadvantages - - Well-known anycast addresses approach requires that DNS servers (or - routers near it as a proxy) act as routers to advertise their - anycast addresses to the routing system, which requires some - configuration (see the last paragraph of the previous section on - the scalability of the effort). - -3.3.3 Observations - - If other approaches are used in addition, the well-known anycast - addresses should also be set in RA or DHCP configuration files to - reduce configuration effort of users. - - Redundancy by multiple RDNSSes is better provided by multiple - servers having different anycast addresses than multiple servers - sharing same anycast address because the former approach allows - stale servers to still generate routes to their anycast addresses. - Thus, in a routing domain (or domains sharing DNS servers), there - will be only one server having an anycast address unless the domain - is so large that load distribution is necessary. - - Small ISPs will operate one RDNSS at each anycast address which is - shared by all the subscribers. Large ISPs may operate multiple - RDNSSes at each anycast address to distribute and reduce load, - where boundary between RDNSSes may be fixed (redundancy is still - provided by multiple addresses) or change dynamically. DNS packets - - -Jeong, et al. Expires - January 2005 [Page 10] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - with the well-known anycast addresses are not expected (though not - prohibited) to cross ISP boundaries, as ISPs are expected to be - able to take care of themselves. - - Because "anycast" in this memo is simpler than that of RFC1546 [11] - and RFC3513 [12] where it is assumed to be administratively - prohibited to have multiple servers on a single link sharing an - anycast address, anycast in this memo should be implemented as - UNICAST of RFC2461 [3] and RFC3513 [12]. As a result, ND-related - instability disappears. Thus, anycast in well-known anycast - addresses approach can and should use the anycast address as a - source unicast (according to RFC3513 [12]) address of packets of - UDP and TCP responses. With TCP, if route flips and packets to an - anycast address are routed to a new server, it is expected that the - flip is detected by ICMP or sequence number inconsistency and the - TCP connection is reset and retried. - -4. Interworking among IPv6 DNS Configuration Approaches - - Three approaches can work together for IPv6 host configuration of - RDNSS. This section shows a consideration on how these approaches - can interwork each other. - - For ordering between RA and DHCP approaches, O (Other stateful - configuration) flag in RA message can be used [8]. If no RDNSS - option is included, an IPv6 Host may perform DNS configuration - through DHCPv6 [5]-[7] regardless of whether the O flag is set or - not. - - The well-known anycast addresses approach fully interworks with the - other approaches. That is, the other approaches can remove - configuration effort on servers by using the well-known addresses - as the default configuration. Moreover, clients preconfigured with - well-known anycast addresses can be further configured to use other - approaches to override the well-known addresses, if configuration - information from other approaches are available. That is, all the - clients should have the well-known anycast addresses preconfigured, - in the case where there are no other mechanisms available. In - order to fly anycast approach with the other solutions, there are - three options. - - The first option is that well-known addresses are used as last - resort, when an IPv6 host can not get RDNSS information through RA - and DHCP. The well-known anycast addresses have to be pre- - configured in IPv6 hosts' resolver configuration files. - - - - - -Jeong, et al. Expires - January 2005 [Page 11] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The second is that an IPv6 host can configure well-known addresses - as the most preferable in its configuration file even though either - RA option or DHCP option is available. - - The last is that the well-known anycast addresses can be set in RA - or DHCP configuration to reduce configuration effort of users. - According to either RA or DHCP mechanism, the well-known addresses - can be obtained by IPv6 host. Because this approach is the most - convenient for users, the last option is recommended. - - Note: this section does not necessarily mean this document suggests - adopting all these three approaches and making them interwork in - the way described here. In fact, some approaches may even not be - adopted at all as a result of further discussion. - -5. Deployment Scenarios - - Regarding DNS configuration on the IPv6 host, several mechanisms - have being considered at the DNSOP Working Group such as RA option, - DHCPv6 option and well-known preconfigured anycast addresses as of - today, and this document is a final result from the long thread. - In this section, we suggest four applicable scenarios of three - approaches for IPv6 DNS configuration. - - Note: in the applicable scenarios, authors do not implicitly push - any specific approaches into the restricted environments. No - enforcement is in each scenario and all mentioned scenarios are - probable. The main objective of this work is to provide a useful - guideline of IPv6 DNS configuration. - -5.1 ISP Network - - A characteristic of ISP network is that multiple Customer Premises - Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) - routers and each PE connects multiple CPE devices to the backbone - network infrastructure [13]. The CPEs may be hosts or routers. - - In the case where the CPE is a router, there is a customer network - that is connected to the ISP backbone through the CPE. Typically, - each customer network gets a different IPv6 prefix from an IPv6 PE - router, but the same RDNSS configuration will be distributed. - - This section discusses how the different approaches to distributing - DNS information are compared in an ISP network. - -5.1.1 RA Option Approach - - - - -Jeong, et al. Expires - January 2005 [Page 12] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - When the CPE is a host, the RA option for RDNSS can be used to - allow the CPE to get RDNSS information as well as /64 prefix - information for stateless address autoconfiguration at the same - time when the host is attached to a new subnet [8]. Because an - IPv6 host must receive at least one RA message for stateless - address autoconfiguration and router configuration, the host could - receive RDNSS configuration information in that RA without the - overhead of an additional message exchange. - - When the CPE is a router, the CPE may accept the RDNSS information - from the RA on the interface connected to the ISP, and copy that - information into the RAs advertised in the customer network. - - This approach is more valuable in the mobile host scenario, in - which the host must receive at least an RA message for detecting a - new network, than in other scenarios generally although - administrator should configure RDNSS information on the routers. - Secure ND [14] can provide extended security when using RA message. - -5.1.2 DHCPv6 Option Approach - - DHCPv6 can be used for RDNSS configuration through the use of the - DNS option, and can provide other configuration information in the - same message with RDNSS configuration [5]-[7]. DHCPv6 DNS option - is already in place for DHCPv6 as RFC 3646 [7] and moreover DHCPv6- - lite or stateless DHCP [6] is nowhere as complex as a full DHCPv6 - implementation. DHCP is a client-server model protocol, so ISP can - handle user identification on its network intentionally, and also - authenticated DHCP [15] can be used for secure message exchange. - - The expected model for deployment of IPv6 service by ISPs is to - assign a prefix to each customer, which will be used by the - customer gateway to assign a /64 prefix to each network in the - customer's network. Prefix delegation with DHCP (DHCPv6 PD) has - already been adopted by ISPs for automating the assignment of the - customer prefix to the customer gateway [17]. DNS configuration - can be carried in the same DHCPv6 message exchange used for DHCPv6 - to efficiently provide that information, along with any other - configuration information needed by the customer gateway or - customer network. This service model can be useful to Home or SOHO - subscribers. The Home or SOHO gateway, which is a customer gateway - for ISP, can then pass that RDNSS configuration information to the - hosts in the customer network through DHCP. - -5.1.3 Well-known Addresses Approach - - Well-known anycast addresses approach is also a feasible and simple - mechanism for ISP [9]. The use of well-known anycast addresses - - -Jeong, et al. Expires - January 2005 [Page 13] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - avoids some of the security risks in rogue messages sent through an - external protocol like RA or DHCPv6. The configuration of hosts - for the use of well-known anycast addresses requires no protocol or - manual configuration, but the configuration of routing for the - anycast addresses requires intervention on the part of the network - administrator. Also, the number of special addresses would be - equal to the number of RDNSSes that could be made available to - subscribers. - -5.2 Enterprise Network - - Enterprise network is defined as a network that has multiple - internal links, one or more router connections, to one or more - Providers and is actively managed by a network operations entity - [16]. An enterprise network can get network prefixes from ISP by - either manual configuration or prefix delegation [17]. In most - cases, because an enterprise network manages its own DNS domains, - it operates its own DNS servers for the domains. These DNS servers - within enterprise network process recursive DNS name resolution - requests of IPv6 hosts as RDNSS. RDNSS configuration in enterprise - network can be performed like in Section 4, in which three - approaches can be used together. - - IPv6 host can decide which approach is or may be used in its subnet - with O flag in RA message [8]. As the first option in Section 4, - well-known anycast addresses can be used as a last resort when - RDNSS information can not be obtained through either RA option or - DHCP option. This case needs IPv6 hosts to preconfigure the well- - known anycast addresses in their DNS configuration files. - - When the enterprise prefers well-known anycast approach to the - others, IPv6 hosts should preconfigure the well-known anycast - addresses like in the first option. - - The last option, a more convenient and transparent way, does not - need IPv6 hosts to preconfigure the well-known anycast addresses - because the addresses are delivered to IPv6 hosts through either RA - option or DHCPv6 option as if they were unicast addresses. This - way is most recommended for the sake of user's convenience. - -5.3 3GPP Network - - IPv6 DNS configuration is a missing part of IPv6 autoconfiguration - and an important part of the basic IPv6 functionality in the 3GPP - User Equipment (UE). Higher level description of the 3GPP - architecture can be found in [18], and transition to IPv6 in 3GPP - networks is analyzed in [19] and [20]. - - - -Jeong, et al. Expires - January 2005 [Page 14] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - In 3GPP architecture, there is a dedicated link between the UE and - the GGSN called the Packet Data Protocol (PDP) Context. This link - is created through the PDP Context activation procedure [21]. - There is a separate PDP context type for IPv4 and IPv6 traffic. If - a 3GPP UE user is communicating using IPv6 (having an active IPv6 - PDP context), it can not be assumed that (s)he has simultaneously - active IPv4 PDP context, and DNS queries could be done using IPv4. - A 3GPP UE can thus be an IPv6 node, and it needs to somehow - discover the address of the RDNSS. Before IP-based services (e.g., - web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS - addresses need to be discovered in the 3GPP UE. - - Section 5.3.1 briefly summarizes currently available mechanisms in - 3GPP networks and recommendations. 5.3.2 analyzes the Router - Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6 - mechanism, and 5.3.4 analyzes the Well-known addresses approach. - Section 5.3.5 finally summarizes the recommendations. - -5.3.1 Currently Available Mechanisms and Recommendations - - 3GPP has defined a mechanism, in which RDNSS addresses can be - received in the PDP context activation (a control plane mechanism). - That is called the Protocol Configuration Options Information - Element (PCO-IE) mechanism [22]. The RDNSS addresses can also be - received over the air (using text messages), or typed in manually - in the UE. Note that the two last mechanisms are not very well - scalable. The UE user most probably does not want to type IPv6 - RDNSS addresses manually in his/her UE. The use of well-known - addresses is briefly discussed in section 5.3.4. - - It is seen that the mechanisms above most probably are not - sufficient for the 3GPP environment. IPv6 is intended to operate - in a zero-configuration manner, no matter what the underlying - network infrastructure is. Typically, the RDNSS address is needed - to make an IPv6 node operational - and the DNS configuration should - be as simple as the address autoconfiguration mechanism. It must - also be noted that there will be additional IP interfaces in some - near future 3GPP UEs, e.g., Wireless LAN (WLAN), and 3GPP-specific - DNS configuration mechanisms (such as PCO-IE [22]) do not work for - those IP interfaces. In other words, a good IPv6 DNS configuration - mechanism should also work in a multi-access network environment. - - From 3GPP point of view, the best IPv6 DNS configuration solution - is feasible for a very large number of IPv6-capable UEs (can be - even hundreds of millions in one operator's network), is automatic - and thus requires no user action. It is suggested to standardize a - lightweight, stateless mechanism that works in all network - environments. The solution could then be used for 3GPP, 3GPP2, - - -Jeong, et al. Expires - January 2005 [Page 15] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - WLAN and other access network technologies. A light, stateless - IPv6 DNS configuration mechanism is thus not only needed in 3GPP - networks, but also 3GPP networks and UEs would certainly benefit - from the new mechanism. - -5.3.2 RA Extension - - Router Advertisement extension [8] is a lightweight IPv6 DNS - configuration mechanism that requires minor changes in 3GPP UE IPv6 - stack and Gateway GPRS Support Node (GGSN, the default router in - the 3GPP architecture) IPv6 stack. This solution can be specified - in the IETF (no action needed in the 3GPP) and taken in use in 3GPP - UEs and GGSNs. - - In this solution, an IPv6-capable UE configures DNS information - via RA message sent by its default router (GGSN), i.e., RDNSS - option for recursive DNS server is included in the RA message. - This solution is easily scalable for a very large number of UEs. - The operator can configure the RDNSS addresses in the GGSN as a - part of normal GGSN configuration. The IPv6 RDNSS address is - received in the Router Advertisement, and an extra Round Trip Time - (RTT) for asking RDNSS addresses can be avoided. - - If thinking about cons, this mechanism still requires - standardization effort in the IETF, and the end nodes and routers - need to support this mechanism. The equipment software update - should, however, be pretty straightforward, and new IPv6 equipment - could support RA extension already from the beginning. - -5.3.3 Stateless DHCPv6 - - DHCPv6-based solution needs the implementation of Stateless DHCP - [6] and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in - the operator's network. A possible configuration is such that the - GGSN works as a DHCP relay. - - Pros for Stateless DHCPv6-based solution are - 1) Stateless DHCPv6 is a standardized mechanism. - - 2) DHCPv6 can be used for receiving other configuration information - than RDNSS addresses, e.g., SIP server addresses. - - 3) DHCPv6 works in different network environments. - - 4) When DHCPv6 service is deployed through a single, centralized - server, the RDNSS configuration information can be updated by the - network administrator at a single source. - - - -Jeong, et al. Expires - January 2005 [Page 16] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - Some issues with DHCPv6 in 3GPP networks are listed below: - 1) DHCPv6 requires an additional server in the network unless the - (Stateless) DHCPv6 functionality is integrated into an existing - router already, and it is one box more to be maintained. - - 2) DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing - (3GPP Stateless Address Autoconfiguration is typically used), and - not automatically implemented in 3GPP IPv6 UEs. - - 3) Scalability and reliability of DHCPv6 in very large 3GPP - networks (with tens or hundreds of millions of UEs) may be an issue, - at least the redundancy needs to be taken care of. However, if the - DHCPv6 service is integrated into the network elements, such as - router operating system, scalability and reliability is comparable - with other DNS configuration approaches. - - 4) It is sub-optimal to utilize the radio resources in 3GPP - networks for DHCPv6 messages if there is a simpler alternative - available. - - a) Use of Stateless DHCPv6 adds one round trip delay to the case - in which the UE can start transmitting data right after the - Router Advertisement. - - 5) If the DNS information (suddenly) changes, Stateless DHCPv6 can - not automatically update the UE, see [23]. - -5.3.4 Well-known Addresses - - Using well-known addresses is also a feasible and a light mechanism - for 3GPP UEs. Those well-known addresses can be preconfigured in - the UE software and the operator makes the corresponding - configuration on the network side. So this is a very easy - mechanism for the UE, but requires some configuration work in the - network. When using well-known addresses, UE forwards queries to - any of the preconfigured addresses. In the current proposal [9], - IPv6 anycast addresses are suggested. - - Note: IPv6 DNS configuration proposal based on the use of well- - known site-local addresses developed at the IPv6 Working Group was - seen as a feasible mechanism for 3GPP UEs, but opposition by some - people in the IETF and finally deprecating IPv6 site-local - addresses made it impossible to standardize it. Note that this - mechanism is implemented in some existing operating systems today - (also in some 3GPP UEs) as a last resort of IPv6 DNS configuration. - -5.3.5 Recommendations - - - -Jeong, et al. Expires - January 2005 [Page 17] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - It is suggested that a lightweight, stateless DNS configuration - mechanism is specified as soon as possible. From 3GPP UE's and - networks' point of view, Router Advertisement based mechanism looks - most promising. The sooner a light, stateless mechanism is - specified, the sooner we can get rid of using well-known site-local - addresses for IPv6 DNS configuration. - -5.4 Unmanaged Network - - There are 4 deployment scenarios of interest in unmanaged networks - [24]: - - 1) A gateway which does not provide IPv6 at all; - - 2) A dual-stack gateway connected to a dual-stack ISP; - - 3) A dual-stack gateway connected to an IPv4-only ISP; and - - 4) A gateway connected to an IPv6-only ISP. - -5.4.1 Case A: Gateway does not provide IPv6 at all - - In this case, the gateway does not provide IPv6; the ISP may or may - not provide IPv6. Automatic or Configured tunnels are the - recommended transition mechanisms for this scenario. - - The case where dual-stack hosts behind an NAT, that need access to - an IPv6 RDNSS, can not be entirely ruled out. The DNS - configuration mechanism has to work over the tunnel, and the - underlying tunneling mechanism could be implementing NAT traversal. - The tunnel server assumes the role of a relay (both for DHCP and - Well-known anycast addresses approaches). - - RA-based mechanism is relatively straightforward in its operation, - assuming the tunnel server is also the IPv6 router emitting RAs. - Well-known anycast addresses approach seems also simple in - operation across the tunnel, but the deployment model using Well- - known anycast addresses in a tunneled environment is unclear or not - well understood. - -5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP - - This is similar to a typical IPv4 home user scenario, where DNS - configuration parameters are obtained using DHCP. Except that - Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the - DHCP server is stateful (maintains the state for clients). - - - - -Jeong, et al. Expires - January 2005 [Page 18] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - -5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP - - This is similar to Case B. If a gateway provides IPv6 connectivity - by managing tunnels, then it is also supposed to provide access to - an RDNSS. Like this, the tunnel for IPv6 connectivity originates - from the dual-stack gateway instead of the host. - -5.4.4 Case D: A gateway connected to an IPv6-only ISP - - This is similar to Case B. - -6. Security Considerations - - As security requirements depend solely on applications and are - different application by application, there can be no generic - requirement defined at higher IP or lower application layer of DNS. - - However, it should be noted that cryptographic security requires - configured secret information that full autoconfiguration and - cryptographic security are mutually exclusive. People insisting on - secure full autoconfiguration will get false security, false - autoconfiguration or both. - - In some deployment scenario [19], where cryptographic security is - required for applications, secret information for the cryptographic - security is preconfigured through which application specific - configuration data, including those for DNS, can be securely - configured. It should be noted that if applications requiring - cryptographic security depend on DNS, the applications also require - cryptographic security to DNS. Therefore, the full auto- - configuration of DNS is not acceptable. - - However, with full autoconfiguration, weaker but still reasonable - security is being widely accepted and will continue to be - acceptable. That is, with full autoconfiguration, which means - there is no cryptographic security for the autoconfiguration, it is - already assumed that local environment is secure enough that - information from local autoconfiguration server has acceptable - security even without cryptographic security. Thus, communication - between a local DNS client and a local DNS server has the - acceptable security. - - For security considerations of each approach, refer to the - corresponding drafts [5]-[9]. - -7. Acknowledgements - - - - -Jeong, et al. Expires - January 2005 [Page 19] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - This draft has greatly benefited from inputs by David Meyer, Rob - Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, - Christian Huitema, and Thomas Narten. The authors appreciate their - contribution. - -8. Normative References - - [1] S. Bradner, "Intellectual Property Rights in IETF Technology", - RFC 3668, February 2004. - - [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February - 2004. - - [3] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for - IP Version 6 (IPv6)", RFC 2461, December 1998. - - [4] S. Thomson and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - [5] R. Droms et al., "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - [6] R. Droms, "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - [7] R. Droms et al., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December - 2003. - -9. Informative References - - [8] J. Jeong, S. Park, L. Beloeil and S. Madanapalli, "IPv6 DNS - Discovery based on Router Advertisement", draft-jeong-dnsop- - ipv6-dns-discovery-02.txt, July 2004. - - [9] M. Ohta, "Preconfigured DNS Server Addresses", draft-ohta- - preconfigured-dns-01.txt, February 2004. - - [10] S. Venaas and T. Chown, "Lifetime Option for DHCPv6", draft- - ietf-dhc-lifetime-00.txt, March 2004. - - [11] C. Partridge, T. Mendez and W. Milliken, "Host Anycasting - Service", RFC 1546, November 1993. - - [12] R. Hinden and S. Deering, "Internet Protocol Version 6 (IPv6) - Addressing Architecture", RFC 3513, April 2003. - - - - -Jeong, et al. Expires - January 2005 [Page 20] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - [13] M. Lind et al., "Scenarios and Analysis for Introduction IPv6 - into ISP Networks", draft-ietf-v6ops-isp-scenarios-analysis- - 02.txt, April 2004. - - [14] J. Arkko et al., "SEcure Neighbor Discovery (SEND)", draft- - ietf-send-ndopt-05.txt, April 2004. - - [15] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", - RFC 3118, June 2001. - - [16] J. Bound et al., "IPv6 Enterprise Network Scenarios", draft- - ietf-v6ops-ent-scenarios-01.txt, February 2004. - - [17] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic Host - Configuration Protocol (DHCP) version 6", RFC 3633, December - 2003. - - [18] M. Wasserman, Ed., "Recommendations for IPv6 in 3GPP - Standards", RFC 3314, September 2002. - - [19] J. Soininen, Ed., "Transition Scenarios for 3GPP Networks", - RFC 3574, August 2003. - - [20] J. Wiljakka, Ed., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-09.txt, March 2004. - - [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); - Service description; Stage 2 (Release 5)", December 2002. - - [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 - specification; Core network protocols; Stage 3 (Release 5)", - June 2003. - - [23] T. Chown, S. Venaas and A. Vijayabhaskar, "Renumbering - Requirements for Stateless DHCPv6", draft-ietf-dhc-stateless- - dhcpv6-renumbering-00.txt, March 2004. - - [24] C. Huitema et al., "Unmanaged Networks IPv6 Transition - Scenarios", RFC 3750, April 2004. - -10. Authors' Addresses - - Jaehoon Paul Jeong, Editor - ETRI / PEC - 161 Gajeong-dong, Yuseong-gu - Daejeon 305-350 - Korea - - - -Jeong, et al. Expires - January 2005 [Page 21] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - Phone: +82 42 860 1664 - Fax: +82 42 861 5404 - EMail: paul@etri.re.kr - - Ralph Droms - Cisco Systems - 1414 Massachusetts Ave. - Boxboro, MA 01719 - USA - - Phone: +1 978 936 1674 - EMail: rdroms@cisco.com - - Robert M. Hinden - Nokia - 313 Fairchild Drive - Mountain View, CA 94043 - USA - - Phone: +1 650 625 2004 - EMail: bob.hinden@nokia.com - - Ted Lemon - Nominum, Inc. - 950 Charter Street - Redwood City, CA 94043 - USA - - EMail: Ted.Lemon@nominum.com - - Masataka Ohta - Graduate School of Information Science and Engineering - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552 - Japan - - Phone: +81 3 5734 3299 - Fax: +81 3 5734 3299 - EMail: mohta@necom830.hpcl.titech.ac.jp - - Soohong Daniel Park - Mobile Platform Laboratory, SAMSUNG Electronics - 416, Maetan-3dong, Paldal-gu, Suwon - Gyeonggi-Do - Korea - - Phone: +82 31 200 4508 - - -Jeong, et al. Expires - January 2005 [Page 22] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - EMail: soohong.park@samsung.com - - Suresh Satapati - Cisco Systems, Inc. - San Jose, CA 95134 - USA - - EMail: satapati@cisco.com - - Juha Wiljakka - Nokia - Visiokatu 3 - FIN-33720 TAMPERE - Finland - - Phone: +358 7180 48372 - EMail: juha.wiljakka@nokia.com - -Intellectual Property Statement - - The following intellectual property notice is copied from RFC3668, - Section 5. - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; nor does it represent that - it has made any independent effort to identify any such rights. - Information on the procedures with respect to rights in RFC - documents can be found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use - of such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository - at http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org. - -Full Copyright Statement - - - - -Jeong, et al. Expires - January 2005 [Page 23] - -Internet-Draft IPv6 Host Configuration of DNS Server July 2004 - - - The following copyright notice is copied from RFC3667, Section 5.4. - It describes the applicable copyright for this document. - - Copyright (C) The Internet Society (2004). This document is - subject to the rights, licenses and restrictions contained in BCP - 78, and except as set forth therein, the authors retain all their - rights. - - This document and the information contained herein are provided on - an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT - THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR - ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A - PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jeong, et al. Expires - January 2005 [Page 24] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt deleted file mode 100644 index b14f711d5314a..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-09.txt +++ /dev/null @@ -1,1969 +0,0 @@ - - -DNS Operations WG A. Durand -Internet-Draft SUN Microsystems, Inc. -Expires: February 7, 2005 J. Ihren - Autonomica - P. Savola - CSC/FUNET - August 9, 2004 - - - - Operational Considerations and Issues with IPv6 DNS - draft-ietf-dnsop-ipv6-dns-issues-09.txt - - -Status of this Memo - - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on February 7, 2005. - - -Copyright Notice - - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - -Abstract - - - This memo presents operational considerations and issues with IPv6 - Domain Name System (DNS), including a summary of special IPv6 - addresses, documentation of known DNS implementation misbehaviour, - recommendations and considerations on how to perform DNS naming for - - - - -Durand, et al. Expires February 7, 2005 [Page 1] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - service provisioning and for DNS resolver IPv6 support, - considerations for DNS updates for both the forward and reverse - trees, and miscellaneous issues. This memo is aimed to include a - summary of information about IPv6 DNS considerations for those who - have experience with IPv4 DNS. - - -Table of Contents - - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4 - 1.2 Independence of DNS Transport and DNS Records . . . . . . 4 - 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5 - 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5 - 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5 - 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6 - 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6 - 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6 - 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7 - 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7 - 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7 - 4. Recommendations for Service Provisioning using DNS . . . . . . 8 - 4.1 Use of Service Names instead of Node Names . . . . . . . . 8 - 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8 - 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9 - 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10 - 4.4.1 Description of Additional Data Scenarios . . . . . . . 10 - 4.4.2 Discussion of the Problems . . . . . . . . . . . . . . 11 - 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 - 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 - 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 - 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 - 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 - 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 - 6. Considerations about Forward DNS Updating . . . . . . . . . . 16 - 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 - 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 - 7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 - 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 - 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 - 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 - 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 - 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 - 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 - 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 - 8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 - - - - -Durand, et al. Expires February 7, 2005 [Page 2] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 - 11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 - A. Site-local Addressing Considerations for DNS . . . . . . . . . 28 - B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 - Intellectual Property and Copyright Statements . . . . . . . . 30 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 3] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -1. Introduction - - - This memo presents operational considerations and issues with IPv6 - DNS; it is meant to be an extensive summary and a list of pointers - for more information about IPv6 DNS considerations for those with - experience with IPv4 DNS. - - - The purpose of this document is to give information about various - issues and considerations related to DNS operations with IPv6; it is - not meant to be a normative specification or standard for IPv6 DNS. - - - The first section gives a brief overview of how IPv6 addresses and - names are represented in the DNS, how transport protocols and - resource records (don't) relate, and what IPv4/IPv6 name space - fragmentation means and how to avoid it; all of these are described - at more length in other documents. - - - The second section summarizes the special IPv6 address types and how - they relate to DNS. The third section describes observed DNS - implementation misbehaviours which have a varying effect on the use - of IPv6 records with DNS. The fourth section lists recommendations - and considerations for provisioning services with DNS. The fifth - section in turn looks at recommendations and considerations about - providing IPv6 support in the resolvers. The sixth and seventh - sections describe considerations with forward and reverse DNS - updates, respectively. The eighth section introduces several - miscellaneous IPv6 issues relating to DNS for which no better place - has been found in this memo. Appendix A looks briefly at the - requirements for site-local addressing. - - -1.1 Representing IPv6 Addresses in DNS Records - - - In the forward zones, IPv6 addresses are represented using AAAA - records. In the reverse zones, IPv6 address are represented using - PTR records in the nibble format under the ip6.arpa. tree. See - [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] - for background information. - - - In particular one should note that the use of A6 records in the - forward tree or Bitlabels in the reverse tree is not recommended - [RFC3363]. Using DNAME records is not recommended in the reverse - tree in conjunction with A6 records; the document did not mean to - take a stance on any other use of DNAME records [RFC3364]. - - -1.2 Independence of DNS Transport and DNS Records - - - DNS has been designed to present a single, globally unique name space - [RFC2826]. This property should be maintained, as described here and - - - - -Durand, et al. Expires February 7, 2005 [Page 4] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - in Section 1.3. - - - The IP version used to transport the DNS queries and responses is - independent of the records being queried: AAAA records can be queried - over IPv4, and A records over IPv6. The DNS servers must not make - any assumptions about what data to return for Answer and Authority - sections based on the underlying transport used in a query. - - - However, there is some debate whether the addresses in Additional - section could be selected or filtered using hints obtained from which - transport was being used; this has some obvious problems because in - many cases the transport protocol does not correlate with the - requests, and because a "bad" answer is in a way worse than no answer - at all (consider the case where the client is led to believe that a - name received in the additional record does not have any AAAA records - at all). - - - As stated in [RFC3596]: - - - The IP protocol version used for querying resource records is - independent of the protocol version of the resource records; e.g., - IPv4 transport can be used to query IPv6 records and vice versa. - - - -1.3 Avoiding IPv4/IPv6 Name Space Fragmentation - - - To avoid the DNS name space from fragmenting into parts where some - parts of DNS are only visible using IPv4 (or IPv6) transport, the - recommendation is to always keep at least one authoritative server - IPv4-enabled, and to ensure that recursive DNS servers support IPv4. - See DNS IPv6 transport guidelines - [I-D.ietf-dnsop-ipv6-transport-guidelines] for more information. - - -1.4 Query Type '*' and A/AAAA Records - - - QTYPE=* is typically only used for debugging or management purposes; - it is worth keeping in mind that QTYPE=* ("ANY" queries) only return - any available RRsets, not *all* the RRsets, because the caches do not - necessarily have all the RRsets and have no way of guaranteeing that - they have all the RRsets. Therefore, to get both A and AAAA records - reliably, two separate queries must be made. - - -2. DNS Considerations about Special IPv6 Addresses - - - There are a couple of IPv6 address types which are somewhat special; - these are considered here. - - - - - - -Durand, et al. Expires February 7, 2005 [Page 5] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -2.1 Limited-scope Addresses - - - The IPv6 addressing architecture [RFC3513] includes two kinds of - local-use addresses: link-local (fe80::/10) and site-local (fec0::/ - 10). The site-local addresses have been deprecated - [I-D.ietf-ipv6-deprecate-site-local], and are only discussed in - Appendix A. - - - Link-local addresses should never be published in DNS (whether in - forward or reverse tree), because they have only local (to the - connected link) significance - [I-D.ietf-dnsop-dontpublish-unreachable]. - - -2.2 Temporary Addresses - - - Temporary addresses defined in RFC3041 [RFC3041] (sometimes called - "privacy addresses") use a random number as the interface identifier. - Publishing (useful) DNS records relating to such addresses would - defeat the purpose of the mechanism and is not recommended. However, - it would still be possible to return a non-identifiable name (e.g., - the IPv6 address in hexadecimal format), as described in [RFC3041]. - - -2.3 6to4 Addresses - - - 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps - a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. - - - If the reverse DNS population would be desirable (see Section 7.1 for - applicability), there are a number of possible ways to do so - [I-D.moore-6to4-dns], some more applicable than the others. - - - The main proposal [I-D.huston-6to4-reverse-dns] aims to design an - autonomous reverse-delegation system that anyone being capable of - communicating using a specific 6to4 address would be able to set up a - reverse delegation to the corresponding 6to4 prefix. This could be - deployed by e.g., Regional Internet Registries (RIRs). This is a - practical solution, but may have some scalability concerns. - - -2.4 Other Transition Mechanisms - - - 6to4, above, is mentioned as a case of an IPv6 transition mechanism - requiring special considerations. In general, mechanisms which - include a special prefix may need a custom solution; otherwise, for - example when IPv4 address is embedded as the suffix or not embedded - at all, special solutions are likely not needed. This is why only - 6to4 and Teredo [I-D.huitema-v6ops-teredo] are described. - - - Note that it does not seem feasible to provide reverse DNS with - - - - -Durand, et al. Expires February 7, 2005 [Page 6] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - another automatic tunneling mechanism, Teredo; this is because the - IPv6 address is based on the IPv4 address and UDP port of the current - NAT mapping which is likely to be relatively short-lived. - - -3. Observed DNS Implementation Misbehaviour - - - Several classes of misbehaviour in DNS servers, load-balancers and - resolvers have been observed. Most of these are rather generic, not - only applicable to IPv6 -- but in some cases, the consequences of - this misbehaviour are extremely severe in IPv6 environments and - deserve to be mentioned. - - -3.1 Misbehaviour of DNS Servers and Load-balancers - - - There are several classes of misbehaviour in certain DNS servers and - load-balancers which have been noticed and documented - [I-D.ietf-dnsop-misbehavior-against-aaaa]: some implementations - silently drop queries for unimplemented DNS records types, or provide - wrong answers to such queries (instead of a proper negative reply). - While typically these issues are not limited to AAAA records, the - problems are aggravated by the fact that AAAA records are being - queried instead of (mainly) A records. - - - The problems are serious because when looking up a DNS name, typical - getaddrinfo() implementations, with AF_UNSPEC hint given, first try - to query the AAAA records of the name, and after receiving a - response, query the A records. This is done in a serial fashion -- - if the first query is never responded to (instead of properly - returning a negative answer), significant timeouts will occur. - - - In consequence, this is an enormous problem for IPv6 deployments, and - in some cases, IPv6 support in the software has even been disabled - due to these problems. - - - The solution is to fix or retire those misbehaving implementations, - but that is likely not going to be effective. There are some - possible ways to mitigate the problem, e.g., by performing the - lookups somewhat in parallel and reducing the timeout as long as at - least one answer has been received; but such methods remain to be - investigated; slightly more on this is included in Section 5. - - -3.2 Misbehaviour of DNS Resolvers - - - Several classes of misbehaviour have also been noticed in DNS - resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem - to directly impair IPv6 use, and are only referred to for - completeness. - - - - - -Durand, et al. Expires February 7, 2005 [Page 7] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -4. Recommendations for Service Provisioning using DNS - - - When names are added in the DNS to facilitate a service, there are - several general guidelines to consider to be able to do it as - smoothly as possible. - - -4.1 Use of Service Names instead of Node Names - - - When a node provides multiple services which should not be - fate-sharing, or might support different IP versions, one should keep - them logically separate in the DNS. Using SRV records [RFC2782] - would avoid these problems. Unfortunately, those are not - sufficiently widely used to be applicable in most cases. Hence an - operation technique is to use service names instead of node names - (or, "hostnames"). This operational technique is not specific to - IPv6, but required to understand the considerations described in - Section 4.2 and Section 4.3. - - - For example, assume a node named "pobox.example.com" provides both - SMTP and IMAP service. Instead of configuring the MX records to - point at "pobox.example.com", and configuring the mail clients to - look up the mail via IMAP from "pobox.example.com", one should use - e.g., "smtp.example.com" for SMTP (for both message submission and - mail relaying between SMTP servers) and "imap.example.com" for IMAP. - Note that in the specific case of SMTP relaying, the server itself - must typically also be configured to know all its names to ensure - loops do not occur. DNS can provide a layer of indirection between - service names and where the service actually is, and using which - addresses. (Obviously, when wanting to reach a specific node, one - should use the hostname rather than a service name.) - - - This is a good practice with IPv4 as well, because it provides more - flexibility and enables easier migration of services from one host to - another. A specific reason why this is relevant for IPv6 is that the - different services may have a different level of IPv6 support -- that - is, one node providing multiple services might want to enable just - one service to be IPv6-visible while keeping some others as - IPv4-only, improving flexibility. - - -4.2 Separate vs the Same Service Names for IPv4 and IPv6 - - - The service naming can be achieved in basically two ways: when a - service is named "service.example.com" for IPv4, the IPv6-enabled - service could be either added to "service.example.com", or added - separately under a different name, e.g., in a sub-domain, like, - "service.ipv6.example.com". - - - These two methods have different characteristics. Using a different - - - - -Durand, et al. Expires February 7, 2005 [Page 8] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - name allows for easier service piloting, minimizing the disturbance - to the "regular" users of IPv4 service; however, the service would - not be used transparently, without the user/application explicitly - finding it and asking for it -- which would be a disadvantage in most - cases. When the different name is under a sub-domain, if the - services are deployed within a restricted network (e.g., inside an - enterprise), it's possible to prefer them transparently, at least to - a degree, by modifying the DNS search path; however, this is a - suboptimal solution. Using the same service name is the "long-term" - solution, but may degrade performance for those clients whose IPv6 - performance is lower than IPv4, or does not work as well (see Section - 4.3 for more). - - - In most cases, it makes sense to pilot or test a service using - separate service names, and move to the use of the same name when - confident enough that the service level will not degrade for the - users unaware of IPv6. - - -4.3 Adding the Records Only when Fully IPv6-enabled - - - The recommendation is that AAAA records for a service should not be - added to the DNS until all of following are true: - - - 1. The address is assigned to the interface on the node. - - - 2. The address is configured on the interface. - - - 3. The interface is on a link which is connected to the IPv6 - infrastructure. - - - In addition, if the AAAA record is added for the node, instead of - service as recommended, all the services of the node should be - IPv6-enabled prior to adding the resource record. - - - For example, if an IPv6 node is isolated from an IPv6 perspective - (e.g., it is not connected to IPv6 Internet) constraint #3 would mean - that it should not have an address in the DNS. - - - Consider the case of two dual-stack nodes, which both have IPv6 - enabled, but the server does not have (global) IPv6 connectivity. As - the client looks up the server's name, only A records are returned - (if the recommendations above are followed), and no IPv6 - communication, which would have been unsuccessful, is even attempted. - - - The issues are not always so black-and-white. Usually it's important - if the service offered using both protocols is of roughly equal - quality, using the appropriate metrics for the service (e.g., - latency, throughput, low packet loss, general reliability, etc.) -- - - - - -Durand, et al. Expires February 7, 2005 [Page 9] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - this is typically very important especially for interactive or - real-time services. In many cases, the quality of IPv6 connectivity - may not yet be equal to that of IPv4, at least globally -- this has - to be taken into consideration when enabling services - [I-D.savola-v6ops-6bone-mess]. - - -4.4 Behaviour of Additional Data in IPv4/IPv6 Environments - - -4.4.1 Description of Additional Data Scenarios - - - Consider the case where the query name is so long, the number of the - additional records is so high, or for other reasons that the entire - response would not fit in a single UDP packet. In some cases, the - responder truncates the response with the TC bit being set (leading - to a retry with TCP), in order for the querier to get the entire - response later. - - - There are two kinds of additional data: - - - 1. glue, i.e., "critical" additional data; this must be included in - all scenarios, with all the RRsets as possible, and - - - 2. "courtesy" additional data; this could be sent in full, with only - a few RRsets, or with no RRsets, and can be fetched separately as - well, but at the cost of additional queries. This data must - never cause setting of the TC bit. - - - The responding server can algorithmically determine which type the - additional data is by checking whether it's at or below a zone cut. - - - Meanwhile, resource record sets (RRsets) are never "broken up", so if - a name has 4 A records and 5 AAAA records, you can either return all - 9, all 4 A records, all 5 AAAA records or nothing. In particular, - notice that for the "critical" additional data getting all the RRsets - can be critical. - - - An example of the "courtesy" additional data is A/AAAA records in - conjunction of MX records as shown in Section 4.5; an example of the - "critical" additional data is shown below (where getting both the A - and AAAA RRsets is critical): - - - child.example.com. IN NS ns.child.example.com. - ns.child.example.com. IN A 192.0.2.1 - ns.child.example.com. IN AAAA 2001:db8::1 - - - When there is too much courtesy additional data, some or all of it - need to be removed [RFC2181]; if some is left in the response, the - issue is which data should be retained. When there is too much - - - - -Durand, et al. Expires February 7, 2005 [Page 10] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - critical additional data, TC bit will have to be set, and some or all - of it need to be removed; if some is left in the response, the issue - is which data should be retained. - - - If the implementation decides to keep as much data as possible, it - might be tempting to use the transport of the DNS query as a hint in - either of these cases: return the AAAA records if the query was done - over IPv6, or return the A records if the query was done over IPv4. - However, this breaks the model of independence of DNS transport and - resource records, as noted in Section 1.2. - - - It is worth remembering that often the host using the records is - different from the node requesting them from the authoritative DNS - server (or even a caching resolver). So, whichever version the - requestor (e.g., a recursive server in the middle) uses makes no - difference to the ultimate user of the records, whose transport - capabilities might differ from those of the requestor. This might - result in e.g., inappropriately returning A records to an IPv6-only - node, going through a translation, or opening up another IP-level - session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]). - Therefore, at least in many scenarios, it would be very useful if the - information returned would be consistent and complete -- or if that - is not feasible, return no misleading information but rather leave it - to the client to query again. - - -4.4.2 Discussion of the Problems - - - As noted above, the temptation for omitting only some of the - additional data based on the transport of the query could be - problematic. In particular, there appears to be little justification - for doing so in the case of "courtesy" data. - - - However, with critical additional data, the alternatives are either - returning nothing (and requiring a retry with TCP) or returning - something (possibly obviating the need for a retry with TCP). If the - process for selecting "something" from the critical data would - otherwise be practically "flipping the coin" between A and AAAA - records, it could be argued that if one looked at the transport of - the query, it would have a larger possibility of being right than - just 50/50. In other words, if the returned critical additional data - would have to be selected somehow, using something more sophisticated - than a random process would seem justifiable. - - - The problem of too much additional data seems to be an operational - one: the zone administrator entering too many records which will be - returned either truncated or missing some RRsets to the users. A - protocol fix for this is using EDNS0 [RFC2671] to signal the capacity - for larger UDP packet sizes, pushing up the relevant threshold. - - - - -Durand, et al. Expires February 7, 2005 [Page 11] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Further, DNS server implementations should rather omit courtesy - additional data completely rather than including only some RRsets - [RFC2181]. An operational fix for this is having the DNS server - implementations return a warning when the administrators create zones - which would result in too much additional data being returned. - Further, DNS server implementations should warn of or disallow such - zone configurations which are recursive or otherwise difficult to - manage by the protocol. - - - Additionally, to avoid the case where an application would not get an - address at all due to some of "courtesy" additional data being - omitted, the resolvers should be able to query the specific records - of the desired protocol, not just rely on getting all the required - RRsets in the additional section. - - -4.5 The Use of TTL for IPv4 and IPv6 RRs - - - In the previous section, we discussed a danger with queries, - potentially leading to omitting RRsets from the additional section; - this could happen to both critical and "courtesy" additional data. - This section discusses another problem with the latter, leading to - omitting RRsets in cached data, highlighted in the IPv4/IPv6 - environment. - - - The behaviour of DNS caching when different TTL values are used for - different RRsets of the same name requires explicit discussion. For - example, let's consider a part of a zone: - - - example.com. 300 IN MX foo.example.com. - foo.example.com. 300 IN A 192.0.2.1 - foo.example.com. 100 IN AAAA 2001:db8::1 - - - When a caching resolver asks for the MX record of example.com, it - gets back "foo.example.com". It may also get back either one or both - of the A and AAAA records in the additional section. So, there are - three cases about returning records for the MX in the additional - section: - - - 1. We get back no A or AAAA RRsets: this is the simplest case, - because then we have to query which information is required - explicitly, guaranteeing that we get all the information we're - interested in. - - - 2. We get back all the RRsets: this is an optimization as there is - no need to perform more queries, causing lower latency. However, - it is impossible to guarantee that in fact we would always get - back all the records (the only way to ensure that is to send a - AAAA query for the name after getting the cached reply with A - - - - -Durand, et al. Expires February 7, 2005 [Page 12] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - records or vice versa). - - - 3. We only get back A or AAAA RRsets even if both existed: this is - indistinguishable from the previous case, and may have problems - at least in certain environments as described in the previous - section. - - - As the third case was considered in the previous section, we assume - we get back both A and AAAA records of foo.example.com, or the stub - resolver explicitly asks, in two separate queries, both A and AAAA - records. - - - After 100 seconds, the AAAA record is removed from the cache(s) - because its TTL expired. It could be argued to be useful for the - caching resolvers to discard the A record when the shorter TTL (in - this case, for the AAAA record) expires; this would avoid the - situation where there would be a window of 200 seconds when - incomplete information is returned from the cache. The behaviour in - this scenario is unspecified. - - - To simplify the situation, it might help to use the same TTL for all - the resource record sets referring to the same name, unless there is - a particular reason for not doing so. However, there are some - scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where - a different strategy is preferable. - - - Thus, applications that use the response should not rely on a - particular TTL configuration. For example, even if an application - gets a response that only has the A record in the example described - above, it should be still aware that there could be a AAAA record for - "foo.example.com". That is, the application should try to fetch the - missing records itself if it needs the record. - - -4.6 IPv6 Transport Guidelines for DNS Servers - - - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue to - be at least one authoritative IPv4 DNS server for every zone, even if - the zone has only IPv6 records. (Note that obviously, having more - servers with robust connectivity would be preferable, but this is the - minimum recommendation; also see [RFC2182].) - - -5. Recommendations for DNS Resolver IPv6 Support - - - When IPv6 is enabled on a node, there are several things to consider - to ensure that the process is as smooth as possible. - - - - - - -Durand, et al. Expires February 7, 2005 [Page 13] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -5.1 DNS Lookups May Query IPv6 Records Prematurely - - - The system library that implements the getaddrinfo() function for - looking up names is a critical piece when considering the robustness - of enabling IPv6; it may come in basically three flavours: - - - 1. The system library does not know whether IPv6 has been enabled in - the kernel of the operating system: it may start looking up AAAA - records with getaddrinfo() and AF_UNSPEC hint when the system is - upgraded to a system library version which supports IPv6. - - - 2. The system library might start to perform IPv6 queries with - getaddrinfo() only when IPv6 has been enabled in the kernel. - However, this does not guarantee that there exists any useful - IPv6 connectivity (e.g., the node could be isolated from the - other IPv6 networks, only having link-local addresses). - - - 3. The system library might implement a toggle which would apply - some heuristics to the "IPv6-readiness" of the node before - starting to perform queries; for example, it could check whether - only link-local IPv6 address(es) exists, or if at least one - global IPv6 address exists. - - - First, let us consider generic implications of unnecessary queries - for AAAA records: when looking up all the records in the DNS, AAAA - records are typically tried first, and then A records. These are - done in serial, and the A query is not performed until a response is - received to the AAAA query. Considering the misbehaviour of DNS - servers and load-balancers, as described in Section 3.1, the look-up - delay for AAAA may incur additional unnecessary latency, and - introduce a component of unreliability. - - - One option here could be to do the queries partially in parallel; for - example, if the final response to the AAAA query is not received in - 0.5 seconds, start performing the A query while waiting for the - result (immediate parallelism might be unoptimal, at least without - information sharing between the look-up threads, as that would - probably lead to duplicate non-cached delegation chain lookups). - - - An additional concern is the address selection, which may, in some - circumstances, prefer AAAA records over A records even when the node - does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault]. - In some cases, the implementation may attempt to connect or send a - datagram on a physical link [I-D.ietf-v6ops-onlinkassumption], - incurring very long protocol timeouts, instead of quickly failing - back to IPv4. - - - Now, we can consider the issues specific to each of the three - - - - -Durand, et al. Expires February 7, 2005 [Page 14] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - possibilities: - - - In the first case, the node performs a number of completely useless - DNS lookups as it will not be able to use the returned AAAA records - anyway. (The only exception is where the application desires to know - what's in the DNS, but not use the result for communication.) One - should be able to disable these unnecessary queries, for both latency - and reliability reasons. However, as IPv6 has not been enabled, the - connections to IPv6 addresses fail immediately, and if the - application is programmed properly, the application can fall - gracefully back to IPv4 [I-D.ietf-v6ops-application-transition]. - - - The second case is similar to the first, except it happens to a - smaller set of nodes when IPv6 has been enabled but connectivity has - not been provided yet; similar considerations apply, with the - exception that IPv6 records, when returned, will be actually tried - first which may typically lead to long timeouts. - - - The third case is a bit more complex: optimizing away the DNS lookups - with only link-locals is probably safe (but may be desirable with - different lookup services which getaddrinfo() may support), as the - link-locals are typically automatically generated when IPv6 is - enabled, and do not indicate any form of IPv6 connectivity. That is, - performing DNS lookups only when a non-link-local address has been - configured on any interface could be beneficial -- this would be an - indication that either the address has been configured either from a - router advertisement, DHCPv6 [RFC3315], or manually. Each would - indicate at least some form of IPv6 connectivity, even though there - would not be guarantees of it. - - - These issues should be analyzed at more depth, and the fixes found - consensus on, perhaps in a separate document. - - -5.2 Obtaining a List of DNS Recursive Resolvers - - - In scenarios where DHCPv6 is available, a host can discover a list of - DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" - option [RFC3646]. This option can be passed to a host through a - subset of DHCPv6 [RFC3736]. - - - The IETF is considering the development of alternative mechanisms for - obtaining the list of DNS recursive name servers when DHCPv6 is - unavailable or inappropriate. No decision about taking on this - development work has been reached as of this writing (Aug 2004) - [I-D.ietf-dnsop-ipv6-dns-configuration]. - - - In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms - under consideration for development include the use of well-known - - - - -Durand, et al. Expires February 7, 2005 [Page 15] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - addresses [I-D.ohta-preconfigured-dns] and the use of Router - Advertisements to convey the information - [I-D.jeong-dnsop-ipv6-dns-discovery]. - - - Note that even though IPv6 DNS resolver discovery is a recommended - procedure, it is not required for dual-stack nodes in dual-stack - networks as IPv6 DNS records can be queried over IPv4 as well as - IPv6. Obviously, nodes which are meant to function without manual - configuration in IPv6-only networks must implement the DNS resolver - discovery function. - - -5.3 IPv6 Transport Guidelines for Resolvers - - - As described in Section 1.3 and - [I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers - should be IPv4-only or dual-stack to be able to reach any IPv4-only - DNS server. Note that this requirement is also fulfilled by an - IPv6-only stub resolver pointing to a dual-stack recursive DNS - resolver. - - -6. Considerations about Forward DNS Updating - - - While the topic how to enable updating the forward DNS, i.e., the - mapping from names to the correct new addresses, is not specific to - IPv6, it should be considered especially due to the advent of - Stateless Address Autoconfiguration [RFC2462]. - - - Typically forward DNS updates are more manageable than doing them in - the reverse DNS, because the updater can often be assumed to "own" a - certain DNS name -- and we can create a form of security relationship - with the DNS name and the node which is allowed to update it to point - to a new address. - - - A more complex form of DNS updates -- adding a whole new name into a - DNS zone, instead of updating an existing name -- is considered out - of scope for this memo as it could require zone-wide authentication. - Adding a new name in the forward zone is a problem which is still - being explored with IPv4, and IPv6 does not seem to add much new in - that area. - - -6.1 Manual or Custom DNS Updates - - - The DNS mappings can also be maintained by hand, in a semi-automatic - fashion or by running non-standardized protocols. These are not - considered at more length in this memo. - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 16] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -6.2 Dynamic DNS - - - Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a standardized - mechanism for dynamically updating the DNS. It works equally well - with stateless address autoconfiguration (SLAAC), DHCPv6 or manual - address configuration. It is important to consider how each of these - behave if IP address-based authentication, instead of stronger - mechanisms [RFC3007], was used in the updates. - - - 1. manual addresses are static and can be configured - - - 2. DHCPv6 addresses could be reasonably static or dynamic, depending - on the deployment, and could or could not be configured on the - DNS server for the long term - - - 3. SLAAC addresses are typically stable for a long time, but could - require work to be configured and maintained. - - - As relying on IP addresses for Dynamic DNS is rather insecure at - best, stronger authentication should always be used; however, this - requires that the authorization keying will be explicitly configured - using unspecified operational methods. - - - Note that with DHCP it is also possible that the DHCP server updates - the DNS, not the host. The host might only indicate in the DHCP - exchange which hostname it would prefer, and the DHCP server would - make the appropriate updates. Nonetheless, while this makes setting - up a secure channel between the updater and the DNS server easier, it - does not help much with "content" security, i.e., whether the - hostname was acceptable -- if the DNS server does not include - policies, they must be included in the DHCP server (e.g., a regular - host should not be able to state that its name is "www.example.com"). - DHCP-initiated DDNS updates have been extensively described in - [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and - [I-D.ietf-dnsext-dhcid-rr]. - - - The nodes must somehow be configured with the information about the - servers where they will attempt to update their addresses, sufficient - security material for authenticating themselves to the server, and - the hostname they will be updating. Unless otherwise configured, the - first could be obtained by looking up the authoritative name servers - for the hostname; the second must be configured explicitly unless one - chooses to trust the IP address-based authentication (not a good - idea); and lastly, the nodename is typically pre-configured somehow - on the node, e.g., at install time. - - - Care should be observed when updating the addresses not to use longer - TTLs for addresses than are preferred lifetimes for the addresses, so - - - - -Durand, et al. Expires February 7, 2005 [Page 17] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - that if the node is renumbered in a managed fashion, the amount of - stale DNS information is kept to the minimum. That is, if the - preferred lifetime of an address expires, the TTL of the record needs - be modified unless it was already done before the expiration. For - better flexibility, the DNS TTL should be much shorter (e.g., a half - or a third) than the lifetime of an address; that way, the node can - start lowering the DNS TTL if it seems like the address has not been - renewed/refreshed in a while. Some discussion on how an - administrator could manage the DNS TTL is included in - [I-D.ietf-v6ops-renumbering-procedure]; this could be applied to - (smart) hosts as well. - - -7. Considerations about Reverse DNS Updating - - - Updating the reverse DNS zone may be difficult because of the split - authority over an address. However, first we have to consider the - applicability of reverse DNS in the first place. - - -7.1 Applicability of Reverse DNS - - - Today, some applications use reverse DNS to either look up some hints - about the topological information associated with an address (e.g. - resolving web server access logs), or as a weak form of a security - check, to get a feel whether the user's network administrator has - "authorized" the use of the address (on the premises that adding a - reverse record for an address would signal some form of - authorization). - - - One additional, maybe slightly more useful usage is ensuring that the - reverse and forward DNS contents match (by looking up the pointer to - the name by the IP address from the reverse tree, and ensuring that a - record under the name in the forward tree points to the IP address) - and correspond to a configured name or domain. As a security check, - it is typically accompanied by other mechanisms, such as a user/ - password login; the main purpose of the reverse+forward DNS check is - to weed out the majority of unauthorized users, and if someone - managed to bypass the checks, he would still need to authenticate - "properly". - - - It may also be desirable to store IPsec keying material corresponding - to an IP address to the reverse DNS, as justified and described in - [I-D.ietf-ipseckey-rr]. - - - It is not clear whether it makes sense to require or recommend that - reverse DNS records be updated. In many cases, it would just make - more sense to use proper mechanisms for security (or topological - information lookup) in the first place. At minimum, the applications - which use it as a generic authorization (in the sense that a record - - - - -Durand, et al. Expires February 7, 2005 [Page 18] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - exists at all) should be modified as soon as possible to avoid such - lookups completely. - - - The applicability is discussed at more length in - [I-D.ietf-dnsop-inaddr-required]. - - -7.2 Manual or Custom DNS Updates - - - Reverse DNS can of course be updated using manual or custom methods. - These are not further described here, except for one special case. - - - One way to deploy reverse DNS would be to use wildcard records, for - example, by configuring one name for a subnet (/64) or a site (/48). - As a concrete example, a site (or the site's ISP) could configure the - reverses of the prefix 2001:db8:f00::/48 to point to one name using a - wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR - site.example.com." Naturally, such a name could not be verified from - the forward DNS, but would at least provide some form of "topological - information" or "weak authorization" if that is really considered to - be useful. Note that this is not actually updating the DNS as such, - as the whole point is to avoid DNS updates completely by manually - configuring a generic name. - - -7.3 DDNS with Stateless Address Autoconfiguration - - - Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in - some regard, while being more difficult in another, as described - below. - - - The address space administrator decides whether the hosts are trusted - to update their reverse DNS records or not. If they are, a simple - address-based authorization is typically sufficient (i.e., check that - the DNS update is done from the same IP address as the record being - updated); stronger security can also be used [RFC3007]. If they - aren't allowed to update the reverses, no update can occur. (Such - address-based update authorization operationally requires that - ingress filtering [RFC3704] has been set up at the border of the site - where the updates occur, and as close to the updater as possible.) - - - Address-based authorization is simpler with reverse DNS (as there is - a connection between the record and the address) than with forward - DNS. However, when a stronger form of security is used, forward DNS - updates are simpler to manage because the host can be assumed to have - an association with the domain. Note that the user may roam to - different networks, and does not necessarily have any association - with the owner of that address space -- so, assuming stronger form of - authorization for reverse DNS updates than an address association is - generally unfeasible. - - - - -Durand, et al. Expires February 7, 2005 [Page 19] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Moreover, the reverse zones must be cleaned up by an unspecified - janitorial process: the node does not typically know a priori that it - will be disconnected, and cannot send a DNS update using the correct - source address to remove a record. - - - A problem with defining the clean-up process is that it is difficult - to ensure that a specific IP address and the corresponding record are - no longer being used. Considering the huge address space, and the - unlikelihood of collision within 64 bits of the interface - identifiers, a process which would remove the record after no traffic - has been seen from a node in a long period of time (e.g., a month or - year) might be one possible approach. - - - To insert or update the record, the node must discover the DNS server - to send the update to somehow, similar to as discussed in Section - 6.2. One way to automate this is looking up the DNS server - authoritative (e.g., through SOA record) for the IP address being - updated, but the security material (unless the IP address-based - authorization is trusted) must also be established by some other - means. - - - One should note that Cryptographically Generated Addresses - [I-D.ietf-send-cga] (CGAs) may require a slightly different kind of - treatment. CGAs are addresses where the interface identifier is - calculated from a public key, a modifier (used as a nonce), the - subnet prefix, and other data. Depending on the usage profile, CGAs - might or might not be changed periodically due to e.g., privacy - reasons. As the CGA address is not predicatable, a reverse record - can only reasonably be inserted in the DNS by the node which - generates the address. - - -7.4 DDNS with DHCP - - - With DHCPv4, the reverse DNS name is typically already inserted to - the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One - can assume similar practice may become commonplace with DHCPv6 as - well; all such mappings would be pre-configured, and would require no - updating. - - - If a more explicit control is required, similar considerations as - with SLAAC apply, except for the fact that typically one must update - a reverse DNS record instead of inserting one (if an address - assignment policy that reassigns disused addresses is adopted) and - updating a record seems like a slightly more difficult thing to - secure. However, it is yet uncertain how DHCPv6 is going to be used - for address assignment. - - - Note that when using DHCP, either the host or the DHCP server could - - - - -Durand, et al. Expires February 7, 2005 [Page 20] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - perform the DNS updates; see the implications in Section 6.2. - - - If disused addresses were to be reassigned, host-based DDNS reverse - updates would need policy considerations for DNS record modification, - as noted above. On the other hand, if disused address were not to be - assigned, host-based DNS reverse updates would have similar - considerations as SLAAC in Section 7.3. Server-based updates have - similar properties except that the janitorial process could be - integrated with DHCP address assignment. - - -7.5 DDNS with Dynamic Prefix Delegation - - - In cases where a prefix, instead of an address, is being used and - updated, one should consider what is the location of the server where - DDNS updates are made. That is, where the DNS server is located: - - - 1. At the same organization as the prefix delegator. - - - 2. At the site where the prefixes are delegated to. In this case, - the authority of the DNS reverse zone corresponding to the - delegated prefix is also delegated to the site. - - - 3. Elsewhere; this implies a relationship between the site and where - DNS server is located, and such a relationship should be rather - straightforward to secure as well. Like in the previous case, - the authority of the DNS reverse zone is also delegated. - - - In the first case, managing the reverse DNS (delegation) is simpler - as the DNS server and the prefix delegator are in the same - administrative domain (as there is no need to delegate anything at - all); alternatively, the prefix delegator might forgo DDNS reverse - capability altogether, and use e.g., wildcard records (as described - in Section 7.2). In the other cases, it can be slighly more - difficult, particularly as the site will have to configure the DNS - server to be authoritative for the delegated reverse zone, implying - automatic configuration of the DNS server -- as the prefix may be - dynamic. - - - Managing the DDNS reverse updates is typically simple in the second - case, as the updated server is located at the local site, and - arguably IP address-based authentication could be sufficient (or if - not, setting up security relationships would be simpler). As there - is an explicit (security) relationship between the parties in the - third case, setting up the security relationships to allow reverse - DDNS updates should be rather straightforward as well (but IP - address-based authentication might not be acceptable). In the first - case, however, setting up and managing such relationships might be a - lot more difficult. - - - - -Durand, et al. Expires February 7, 2005 [Page 21] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -8. Miscellaneous DNS Considerations - - - This section describes miscellaneous considerations about DNS which - seem related to IPv6, for which no better place has been found in - this document. - - -8.1 NAT-PT with DNS-ALG - - - The DNS-ALG component of NAT-PT mangles A records to look like AAAA - records to the IPv6-only nodes. Numerous problems have been - identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues]. - This is a strong reason not to use NAT-PT in the first place. - - -8.2 Renumbering Procedures and Applications' Use of DNS - - - One of the most difficult problems of systematic IP address - renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that - an application which looks up a DNS name disregards information such - as TTL, and uses the result obtained from DNS as long as it happens - to be stored in the memory of the application. For applications - which run for a long time, this could be days, weeks or even months; - some applications may be clever enough to organize the data - structures and functions in such a manner that look-ups get refreshed - now and then. - - - While the issue appears to have a clear solution, "fix the - applications", practically this is not reasonable immediate advice; - the TTL information is not typically available in the APIs and - libraries (so, the advice becomes "fix the applications, APIs and - libraries"), and a lot more analysis is needed on how to practically - go about to achieve the ultimate goal of avoiding using the names - longer than expected. - - -9. Acknowledgements - - - Some recommendations (Section 4.3, Section 5.1) about IPv6 service - provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik - Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided - useful feedback and improvements. Scott Rose, Rob Austein, Masataka - Ohta, and Mark Andrews helped in clarifying the issues regarding - additional data and the use of TTL. Jefsey Morfin, Ralph Droms, - Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and - Rob Austein provided useful feedback during the WG last call. Thomas - Narten provided extensive feedback during the IESG evaluation. - - -10. Security Considerations - - - This document reviews the operational procedures for IPv6 DNS - - - - -Durand, et al. Expires February 7, 2005 [Page 22] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - operations and does not have security considerations in itself. - - - However, it is worth noting that in particular with Dynamic DNS - Updates, security models based on the source address validation are - very weak and cannot be recommended -- they could only be considered - in the environments where ingress filtering [RFC3704] has been - deployed. On the other hand, it should be noted that setting up an - authorization mechanism (e.g., a shared secret, or public-private - keys) between a node and the DNS server has to be done manually, and - may require quite a bit of time and expertise. - - - To re-emphasize which was already stated, the reverse+forward DNS - check provides very weak security at best, and the only - (questionable) security-related use for them may be in conjunction - with other mechanisms when authenticating a user. - - -11. References - - -11.1 Normative References - - - [I-D.ietf-dnsop-ipv6-dns-configuration] - Jeong, J., "IPv6 Host Configuration of DNS Server - Information Approaches", - draft-ietf-dnsop-ipv6-dns-configuration-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-ipv6-transport-guidelines] - Durand, A. and J. Ihren, "DNS IPv6 transport operational - guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02 - (work in progress), March 2004. - - - [I-D.ietf-dnsop-misbehavior-against-aaaa] - Morishita, Y. and T. Jinmei, "Common Misbehavior against - DNS Queries for IPv6 Addresses", - draft-ietf-dnsop-misbehavior-against-aaaa-01 (work in - progress), April 2004. - - - [I-D.ietf-ipv6-deprecate-site-local] - Huitema, C. and B. Carpenter, "Deprecating Site Local - Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work - in progress), March 2004. - - - [I-D.ietf-v6ops-application-transition] - Shin, M., "Application Aspects of IPv6 Transition", - draft-ietf-v6ops-application-transition-03 (work in - progress), June 2004. - - - [I-D.ietf-v6ops-renumbering-procedure] - - - - -Durand, et al. Expires February 7, 2005 [Page 23] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Baker, F., Lear, E. and R. Droms, "Procedures for - Renumbering an IPv6 Network without a Flag Day", - draft-ietf-v6ops-renumbering-procedure-01 (work in - progress), July 2004. - - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - - [RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - - [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. - - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - - [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for - Stateless Address Autoconfiguration in IPv6", RFC 3041, - January 2001. - - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - - [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, - August 2001. - - - [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and - M. Carney, "Dynamic Host Configuration Protocol for IPv6 - (DHCPv6)", RFC 3315, July 2003. - - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - - [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) - Support for Internet Protocol version 6 (IPv6)", RFC 3364, - August 2002. - - - - - -Durand, et al. Expires February 7, 2005 [Page 24] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 - (IPv6) Addressing Architecture", RFC 3513, April 2003. - - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October - 2003. - - - [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host - Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, - December 2003. - - - [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol - (DHCP) Service for IPv6", RFC 3736, April 2004. - - -11.2 Informative References - - - [I-D.durand-v6ops-natpt-dns-alg-issues] - Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", - draft-durand-v6ops-natpt-dns-alg-issues-00 (work in - progress), February 2003. - - - [I-D.huitema-v6ops-teredo] - Huitema, C., "Teredo: Tunneling IPv6 over UDP through - NATs", draft-huitema-v6ops-teredo-02 (work in progress), - June 2004. - - - [I-D.huston-6to4-reverse-dns] - Huston, G., "6to4 Reverse DNS", - draft-huston-6to4-reverse-dns-02 (work in progress), April - 2004. - - - [I-D.ietf-dhc-ddns-resolution] - Stapp, M., "Resolution of DNS Name Conflicts Among DHCP - Clients", draft-ietf-dhc-ddns-resolution-07 (work in - progress), July 2004. - - - [I-D.ietf-dhc-fqdn-option] - Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option", - draft-ietf-dhc-fqdn-option-07 (work in progress), July - 2004. - - - [I-D.ietf-dnsext-dhcid-rr] - Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for - encoding DHCP information (DHCID RR)", - draft-ietf-dnsext-dhcid-rr-08 (work in progress), July - 2004. - - - [I-D.ietf-dnsop-bad-dns-res] - - - - -Durand, et al. Expires February 7, 2005 [Page 25] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Larson, M. and P. Barber, "Observed DNS Resolution - Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in - progress), July 2004. - - - [I-D.ietf-dnsop-dontpublish-unreachable] - Hazel, P., "IP Addresses that should never appear in the - public DNS", draft-ietf-dnsop-dontpublish-unreachable-03 - (work in progress), February 2002. - - - [I-D.ietf-dnsop-inaddr-required] - Senie, D., "Requiring DNS IN-ADDR Mapping", - draft-ietf-dnsop-inaddr-required-05 (work in progress), - April 2004. - - - [I-D.ietf-ipseckey-rr] - Richardson, M., "A method for storing IPsec keying - material in DNS", draft-ietf-ipseckey-rr-11 (work in - progress), July 2004. - - - [I-D.ietf-ipv6-unique-local-addr] - Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast - Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in - progress), June 2004. - - - [I-D.ietf-send-cga] - Aura, T., "Cryptographically Generated Addresses (CGA)", - draft-ietf-send-cga-06 (work in progress), April 2004. - - - [I-D.ietf-v6ops-3gpp-analysis] - Wiljakka, J., "Analysis on IPv6 Transition in 3GPP - Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in - progress), May 2004. - - - [I-D.ietf-v6ops-mech-v2] - Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms - for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04 - (work in progress), July 2004. - - - [I-D.ietf-v6ops-onlinkassumption] - Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery - On-Link Assumption Considered Harmful", - draft-ietf-v6ops-onlinkassumption-02 (work in progress), - May 2004. - - - [I-D.ietf-v6ops-v6onbydefault] - Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack - IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 - (work in progress), July 2004. - - - - -Durand, et al. Expires February 7, 2005 [Page 26] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - [I-D.jeong-dnsop-ipv6-dns-discovery] - Jeong, J., "IPv6 DNS Discovery based on Router - Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 - (work in progress), July 2004. - - - [I-D.moore-6to4-dns] - Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work - in progress), October 2002. - - - [I-D.ohta-preconfigured-dns] - Ohta, M., "Preconfigured DNS Server Addresses", - draft-ohta-preconfigured-dns-01 (work in progress), - February 2004. - - - [I-D.savola-v6ops-6bone-mess] - Savola, P., "Moving from 6bone to IPv6 Internet", - draft-savola-v6ops-6bone-mess-01 (work in progress), - November 2002. - - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - - [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - - [RFC2826] Internet Architecture Board, "IAB Technical Comment on the - Unique DNS Root", RFC 2826, May 2000. - - - [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed - Networks", BCP 84, RFC 3704, March 2004. - - - -Authors' Addresses - - - Alain Durand - SUN Microsystems, Inc. - 17 Network circle UMPL17-202 - Menlo Park, CA 94025 - USA - - - EMail: Alain.Durand@sun.com - - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 27] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - Johan Ihren - Autonomica - Bellmansgatan 30 - SE-118 47 Stockholm - Sweden - - - EMail: johani@autonomica.se - - - - Pekka Savola - CSC/FUNET - Espoo - Finland - - - EMail: psavola@funet.fi - - -Appendix A. Site-local Addressing Considerations for DNS - - - As site-local addressing has been deprecated, the considerations for - site-local addressing are discussed briefly here. Unique local - addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed - as a replacement, but being work-in-progress, it is not considered - further. - - - The interactions with DNS come in two flavors: forward and reverse - DNS. - - - To actually use site-local addresses within a site, this implies the - deployment of a "split-faced" or a fragmented DNS name space, for the - zones internal to the site, and the outsiders' view to it. The - procedures to achieve this are not elaborated here. The implication - is that site-local addresses must not be published in the public DNS. - - - To faciliate reverse DNS (if desired) with site-local addresses, the - stub resolvers must look for DNS information from the local DNS - servers, not e.g. starting from the root servers, so that the - site-local information may be provided locally. Note that the - experience of private addresses in IPv4 has shown that the root - servers get loaded for requests for private address lookups in any - case. - - -Appendix B. Issues about Additional Data or TTL - - - [[ note to the RFC-editor: remove this section upon publication. ]] - - - This appendix tries to describe the apparent rought consensus about - additional data and TTL issues (sections 4.4 and 4.5), and present - questions when there appears to be no consensus. The point of - - - - -Durand, et al. Expires February 7, 2005 [Page 28] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - - recording them here is to focus the discussion and get feedback. - - - Resolved: - - - a. If some critical additional data RRsets wouldn't fit, you set the - TC bit even if some RRsets did fit. - - - b. If some courtesy additional data RRsets wouldn't fit, you never - set the TC bit, but rather remove (at least some of) the courtesy - RRsets. - - - c. DNS servers should implement sanity checks on the resulting glue, - e.g., to disable circular dependencies. Then the responding - servers can use at-or-below-a-zone-cut criterion to determine - whether the additional data is critical or not. - - - Open issues (at least): - - - 1. if some critical additional data RRsets would fit, but some - wouldn't, and TC has to be set (see above), should one rather - remove the additional data that did fit, keep it, or leave - unspecified? - - - 2. if some courtesy additional data RRsets would fit, but some - wouldn't, and some will have to be removed from the response (no - TC is set, see above), what to do -- remove all courtesy RRsets, - keep all that fit, or leave unspecified? - - - 3. is it acceptable to use the transport used in the DNS query as a - hint which records to keep if not removing all the RRsets, if: a) - having to decide which critical additional data to keep, or b) - having to decide which courtesy additional data to keep? - - - 4. (this issue was discussed in section 4.5) if one RRset has TTL of - 100 seconds, and another the TTL of 300 seconds, what should the - caching server do after 100 seconds? Keep returning just one - RRset when returning additional data, or discard the other RRset - from the cache? - - - 5. how do we move forward from here? If we manage to get to some - form of consensus, how do we record it: a) just in - draft-ietf-dnsop-ipv6-dns-issues (note that it's Informational - category only!), b) a separate BCP or similar by DNSEXT WG(?), - clarifying and giving recommendations, c) something else, what? - - - - - - - - -Durand, et al. Expires February 7, 2005 [Page 29] -Internet-Draft Considerations and Issues with IPv6 DNS August 2004 - - - -Intellectual Property Statement - - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - -Disclaimer of Validity - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - -Copyright Statement - - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - - -Acknowledgment - - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - -Durand, et al. Expires February 7, 2005 [Page 30]
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt deleted file mode 100644 index b2e2341be9f16..0000000000000 --- 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-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt deleted file mode 100644 index 2311ee6c18a01..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt +++ /dev/null @@ -1,391 +0,0 @@ - -DNSOP G. Guette -Internet-Draft IRISA / INRIA -Expires: February 5, 2005 O. Courtay - Thomson R&D - August 7, 2004 - - - Requirements for Automated Key Rollover in DNSSEC - draft-ietf-dnsop-key-rollover-requirements-01.txt - -Status of this Memo - - By submitting this Internet-Draft, I certify that any applicable - patent or other IPR claims of which I am aware have been disclosed, - and any of which I become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on February 5, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document describes problems that appear during an automated - rollover and gives the requirements for the design of communication - between parent zone and child zone in an automated rollover process. - This document is essentially about key rollover, the rollover of - another Resource Record present at delegation point (NS RR) is also - discussed. - - - - - -Guette & Courtay Expires February 5, 2005 [Page 1] - -Internet-Draft Automated Rollover Requirements August 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3 - 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4 - 4. Messages authentication and information exchanged . . . . . . 4 - 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5 - 6. Other Resource Record concerned by automatic rollover . . . . 5 - 7. Security consideration . . . . . . . . . . . . . . . . . . . . 5 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 - Intellectual Property and Copyright Statements . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Guette & Courtay Expires February 5, 2005 [Page 2] - -Internet-Draft Automated Rollover Requirements August 2004 - - -1. Introduction - - The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key - cryptography and digital signatures. It stores the public part of - keys in DNSKEY Resource Records (RRs). Because old keys and - frequently used keys are vulnerable, they must be renewed - periodically. In DNSSEC, this is the case for Zone Signing Keys - (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key - rollover process is necessary for large zones because there are too - many changes to handle a manual administration. - - Let us consider for example a zone with 100000 secure delegations. - If the child zones change their keys once a year on average, that - implies 300 changes per day for the parent zone. This amount of - changes are hard to manage manually. - - Automated rollover is optional and resulting from an agreement - between the administrator of the parent zone and the administrator of - the child zone. Of course, key rollover can also be done manually by - administrators. - - This document describes the requirements for the design of messages - of automated key rollover process and focusses on interaction between - parent and child zone. - -2. The Key Rollover Process - - Key rollover consists in renewing the DNSSEC keys used to sign - resource records in a given DNS zone file. There are two types of - rollover, ZSK rollovers and KSK rollovers. - - In a ZSK rollover, all changes are local to the zone that renews its - key: there is no need to contact other zones (e.g., parent zone) to - propagate the performed changes because a ZSK has no associated DS - record in the parent zone. - - In a KSK rollover, new DS RR(s) must be created and stored in the - parent zone. In consequence, the child zone must contact its parent - zone and must notify it about the KSK change(s). - - Manual key rollover exists and works [3]. The key rollover is built - from two parts of different nature: - o An algorithm that generates new keys and signs the zone file. It - could be local to the zone - o The interaction between parent and child zones - - One example of manual key rollover is: - - - - -Guette & Courtay Expires February 5, 2005 [Page 3] - -Internet-Draft Automated Rollover Requirements August 2004 - - - o The child zone creates a new KSK - o The child zone waits for the creation of the DS RR in its parent - zone - o The child zone deletes the old key. - - In manual rollover, communications are managed by the zone - administrators and the security of these communications is out of - scope of DNSSEC. - - Automated key rollover should use a secure communication between - parent and child zones. This document concentrates on defining - interactions between entities present in key rollover process. - -3. Basic Requirements - - The main constraint to respect during a key rollover is that the - chain of trust MUST be preserved, even if a resolver retrieves some - RRs from recursive cache server. Every RR MUST be verifiable at any - time, every RRs exchanged during the rollover should be authenticated - and their integrity should be guaranteed. - - Two entities act during a KSK rollover: the child zone and its parent - zone. These zones are generally managed by different administrators. - These administrators should agree on some parameters like - availability of automated rollover, the maximum delay between - notification of changes in the child zone and the resigning of the - parent zone. The child zone needs to know this delay to schedule its - changes. - -4. Messages authentication and information exchanged - - Every exchanged message MUST be authenticated and the authentication - tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC - request with verifiable SIG records. - - Once the changes related to a KSK are made in a child zone, this zone - MUST notify its parent zone in order to create the new DS RR and - store this DS RR in parent zone file. - - The parent zone MUST receive all the child keys that needs the - creation of associated DS RRs in the parent zone. - - Some errors could occur during transmission between child zone and - parent zone. Key rollover solution MUST be fault tolerant, i.e. at - any time the rollover MUST be in a consistent state and all RRs MUST - be verifiable, even if an error occurs. That is to say that it MUST - remain a valid chain of trust. - - - - -Guette & Courtay Expires February 5, 2005 [Page 4] - -Internet-Draft Automated Rollover Requirements August 2004 - - -5. Emergency Rollover - - A key of a zone might be compromised and this key MUST be changed as - soon as possible. Fast changes could break the chain of trust. The - part of DNS tree having this zone as apex can become unverifiable, - but the break of the chain of trust is necessary if we want to no one - can use the compromised key to spoof DNS data. - - In case of emergency rollover, the administrators of parent and child - zones should create new key(s) and DS RR(s) as fast as possible in - order to reduce the time the chain of trust is broken. - -6. Other Resource Record concerned by automatic rollover - - NS records are also present at delegation point, so when the child - zone renews some NS RR, the corresponding records at delegation point - in parent zone (glue) MUST be updated. NS records are concerned by - rollover and this rollover could be automated too. In this case, - when the child zone notifies its parent zone that some NS records - have been changed, the parent zone MUST verify that these NS records - are present in child zone before doing any changes in its own zone - file. This allows to avoid inconsistency between NS records at - delegation point and NS records present in the child zone. - -7. Security consideration - - This document describes requirements to design an automated key - rollover in DNSSEC based on DNSSEC security. In the same way, as - plain DNSSEC, the automatic key rollover contains no mechanism - protecting against denial of service (DoS). The security level - obtain after an automatic key rollover, is the security level - provided by DNSSEC. - -8. Acknowledgments - - The authors want to acknowledge Francis Dupont, Mohsen Souissi, - Bernard Cousin, Bertrand L‰onard and members of IDsA project for - their contribution to this document. - -9 Normative References - - [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", - RFC 3658, December 2003. - - [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY - (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag", - RFC 3757, May 2004. - - - - -Guette & Courtay Expires February 5, 2005 [Page 5] - -Internet-Draft Automated Rollover Requirements August 2004 - - - [3] Kolkman, O., "DNSSEC Operational Practices", - draft-ietf-dnsop-dnssec-operational-practice-01 (work in - progress), May 2004. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [5] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, - "Secret Key Transaction Authentication for DNS (TSIG)", RFC - 2845, May 2000. - - [7] Arends, R., "Resource Records for the DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-09 (work in progress), July - 2004. - - [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, - "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004. - - [9] Arends, R., "Protocol Modifications for the DNS Security - Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in - progress), July 2004. - - -Authors' Addresses - - Gilles Guette - IRISA / INRIA - Campus de Beaulieu - 35042 Rennes CEDEX - FR - - EMail: gilles.guette@irisa.fr - URI: http://www.irisa.fr - - - Olivier Courtay - Thomson R&D - 1, avenue Belle Fontaine - 35510 Cesson S‰vign‰ CEDEX - FR - - EMail: olivier.courtay@thomson.net - - - - - -Guette & Courtay Expires February 5, 2005 [Page 6] - -Internet-Draft Automated Rollover Requirements August 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Guette & Courtay Expires February 5, 2005 [Page 7] - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt deleted file mode 100644 index 1094275d3e40a..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-misbehavior-against-aaaa-00.txt +++ /dev/null @@ -1,505 +0,0 @@ - - -IETF DNSOP Working Group Y. Morishita -Internet-Draft JPRS -Expires: July 11, 2004 T. Jinmei - Toshiba - January 11, 2004 - - - Common Misbehavior against DNS Queries for IPv6 Addresses - draft-ietf-dnsop-misbehavior-against-aaaa-00.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on July 11, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - There is some known misbehavior of DNS authoritative servers when - they are queried for AAAA resource records. Such behavior can block - IPv4 communication which should actually be available, cause a - significant delay in name resolution, or even make a denial of - service attack. This memo describes details of the known cases and - discusses the effect of the cases. - -1. Introduction - - Many DNS clients (resolvers) that support IPv6 first search for AAAA - Resource Records (RRs) of a target host name, and then for A RRs of - - - -Morishita & Jinmei Expires July 11, 2004 [Page 1] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - the same name. This fallback mechanism is based on the DNS - specifications, which if not obeyed by authoritative servers can - produce unpleasant results. In some cases, for example, a web browser - fails to connect to a web server it could otherwise. In the following - sections, this memo describes some typical cases of the misbehavior - and its (bad) effects. - - Note that the misbehavior is not specific to AAAA RRs. In fact, all - known examples also apply to the cases of queries for MX, NS, and SOA - RRs. The authors even believe this can be generalized for all types - of queries other than those for A RRs. In this memo, however, we - concentrate on the case for AAAA queries, since the problem is - particularly severe for resolvers that support IPv6, which thus - affects many end users. Resolvers at end users normally send A and/or - AAAA queries only, and so the problem for the other cases is - relatively minor. - -2. Network Model - - In this memo, we assume a typical network model of name resolution - environment using DNS. It consists of three components; stub - resolvers, caching servers, and authoritative servers. A stub - resolver issues a recursive query to a caching server, which then - handles the entire name resolution procedure recursively. The caching - server caches the result of the query as well as sends the result to - the stub resolver. The authoritative servers respond to queries for - names for which they have the authority, normally in a non-recursive - manner. - -3. Expected Behavior - - Suppose that an authoritative server has an A RR but not a AAAA RR - for a host name. Then the server should return a response to a query - for a AAAA RR of the name with the RCODE being 0 (indicating no - error) and with an empty answer section [1]. Such a response - indicates that there is at least one RR of a different type than AAAA - for the queried name, and the stub resolver can then look for A RRs. - - This way, the caching server can cache the fact that the queried name - does not have a AAAA RR (but may have other types of RRs), and thus - can improve the response time to further queries for a AAAA RR of the - name. - -4. Problematic Behaviors - - There are some known cases at authoritative servers that do not - conform to the expected behavior. This section describes those - problematic cases. - - - -Morishita & Jinmei Expires July 11, 2004 [Page 2] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -4.1 Return NXDOMAIN - - This type of server returns a response with the RCODE being 3 - (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any - RRs of any type for the queried name. - - With this response, the stub resolver may immediately give up and - never fall back. Even if the resolver retries with a query for an A - RR, the negative response for the name has been cached in the caching - server, and the caching server will simply return the negative - response. As a result, the stub resolver considers this as a fatal - error in name resolution. - - There have been several known examples of this behavior, but all the - examples that the authors know have changed their behavior as of this - writing. - -4.2 Return NOTIMP - - Other authoritative servers return a response with the RCODE being 4 - (NOTIMP), indicating the servers do not support the requested type of - query. - - This case is less harmful than the previous one; if the stub resolver - falls back to querying for an A RR, the caching server will process - the query correctly and return an appropriate response. - - In this case, the caching server does not cache the fact that the - queried name has no AAAA RR, resulting in redundant queries for AAAA - RRs in the future. The behavior will waste network bandwidth and - increase the load of the authoritative server. - - Using SERVFAIL or FORMERR would cause the same effect, though the - authors have not seen such implementations yet. - -4.3 Return a Broken Response - - Another different type of authoritative servers returns broken - responses to AAAA queries. A known behavior of this category is to - return a response whose RR type is AAAA, but the length of the RDATA - is 4 bytes. The 4-byte data looks like the IPv4 address of the - queried host name. That is, the RR in the answer section would be - described like this: - - www.bad.example. 600 IN AAAA 192.0.2.1 - - which is, of course, bogus (or at least meaningless). - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 3] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - A widely deployed caching server implementation transparently returns - the broken response (as well as caches it) to the stub resolver. - Another known server implementation parses the response by - themselves, and sends a separate response with the RCODE being 2 - (SERVFAIL). - - In either case, the broken response does not affect queries for an A - RR of the same name. If the stub resolver falls back to A queries, it - will get an appropriate response. - - The latter case, however, causes the same bad effect as that - described in the previous section: redundant queries for AAAA RRs. - -4.4 Make Lame Delegation - - Some authoritative servers respond to AAAA queries in a way causing - lame delegation. In this case the parent zone specifies that the - authoritative server should have the authority of a zone, but the - server does not return an authoritative response for AAAA queries - within the zone (i.e., the AA bit in the response is not set). On the - other hand, the authoritative server returns an authoritative - response for A queries. - - When a caching server asks the server for AAAA RRs in the zone, it - recognizes the delegation is lame, and return a response with the - RCODE being 2 (SERVFAIL) to the stub resolver. - - Furthermore, some caching servers record the authoritative server as - lame for the zone and will not use it for a certain period of time. - With this type of caching server, even if the stub resolver falls - back to querying for an A RR, the caching server will simply return a - response with the RCODE being SERVFAIL, since all the servers are - known to be "lame." - - There is also an implementation that relaxes the behavior a little - bit. It basically tries to avoid using the lame server, but still - continues to try it as a last resort. With this type of caching - server, the stub resolver will get a correct response if it falls - back after SERVFAIL. However, this still causes redundant AAAA - queries as explained in the previous sections. - -4.5 Ignore Queries for AAAA - - Some authoritative severs seem to ignore queries for a AAAA RR, - causing a delay at the stub resolver to fall back to a query for an A - RR. This behavior may even cause a fatal timeout at the resolver. - - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 4] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -5. Security Considerations - - The CERT/CC pointed out that the response with NXDOMAIN described in - Section 4.1 can be used for a denial of service attack [2]. The same - argument applies to the case of "lame delegation" described in - Section 4.4 with a certain type of caching server. - -6. Acknowledgements - - Erik Nordmark encouraged the authors to publish this document as an - Internet Draft. Akira Kato and Paul Vixie reviewed a preliminary - version of this document. Pekka Savola carefully reviewed a previous - version and provided detailed comments. - -Informative References - - [1] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC - 1034, November 1987. - - [2] The CERT Coordination Center, "Incorrect NXDOMAIN responses from - AAAA queries could cause denial-of-service conditions", March - 2003, <http://www.kb.cert.org/vuls/id/714121>. - - -Authors' Addresses - - MORISHITA Orange Yasuhiro - Research and Development Department, Japan Registry Service Co.,Ltd. - Fuundo Bldg 3F, 1-2 Kanda-Ogawamachi - Chiyoda-ku, Tokyo 101-0052 - Japan - - EMail: yasuhiro@jprs.co.jp - - - JINMEI Tatuya - Corporate Research & Development Center, Toshiba Corporation - 1 Komukai Toshiba-cho, Saiwai-ku - Kawasaki-shi, Kanagawa 212-8582 - Japan - - EMail: jinmei@isl.rdc.toshiba.co.jp - -Appendix A. Live Examples - - In this appendix, we show concrete implementations and domain names - that may cause problematic cases so that the behavior can be - reproduced in a practical environment. The examples are for - - - -Morishita & Jinmei Expires July 11, 2004 [Page 5] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - informational purposes only, and the authors do not intend to accuse - any implementations or zone administrators. - - The behavior described in Section 4.2 (return NOTIMP) can be found by - looking for a AAAA RR of www.css.vtext.com at 66.174.3.4. - - The behavior described in Section 4.3 (broken responses) can be seen - by querying for a AAAA RR of "www.gslb.mainichi.co.jp," which is an - alias of "www.mainichi.co.jp," at 210.173.172.2. The same behavior - can be found with the name "vip.alt.ihp.sony.co.jp," an alias of - "www.sony.co.jp," at 210.139.255.204. - - The behavior described in Section 4.4 (lame delegation) can be found - by querying for a AAAA RR of "www.ual.com" at 209.87.113.4. - - The behavior described in Section 4.5 (ignore queries) can be seen by - trying to ask for a AAAA RR of "ad.3jp.doubleclick.net," which is an - alias of "ad.jp.doubleclick.net," at 210.153.90.9. - - Many authoritative server implementations show the expected behavior - described in Section 3. Some DNS load balancers reportedly have a - problematic behavior shown in Section 4, but the authors do not have - a concrete example. The CERT/CC provides a list of implementations - that behave as described in Section 4.1 [2]. - - The BIND9 caching server implementation is an example of the latter - cases described in Section 4.3 and Section 4.4, respectively. The - BIND8 caching server implementation is an example of the former case - described in Section 4.3. As for the issue shown in Section 4.4, - BIND8 caching servers prior to 8.3.5 show the behavior described as - the former case in this section. The versions 8.3.5 and later of - BIND8 caching server behave like the BIND9 caching server - implementation with this matter. - - Regarding resolver implementations, the authors are only familiar - with the ones derived from the BIND implementation. These - implementations always fall back regardless of the RCODE; NXDOMAIN, - NOTIMP, or SERVFAIL. It even falls back when getting a broken - response. However, the behavior does not help the situation in the - NXDOMAIN case (see Section 4.1). Lame delegation (Section 4.4) also - causes a fatal error at the resolver side if the resolver is using - some older versions of BIND8 caching server. - - The authors hear that a stub resolver routine implemented in some web - browsers interprets the broken response described in Section 4.3 as a - fatal error and does not fall back to A queries. However, we have not - confirmed this information. - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 6] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -Appendix B. Change History - - Changes since draft-morishita-dnsop-misbehavior-against-aaaa-00 are: - - o Made a separate appendix and moved live examples to appendix so - that we can remove them when this document is (ever) officially - published. - - o Revised some live examples based on the recent status. - - o Noted in introduction that the misbehavior is not specific to AAAA - and that this document still concentrates on the AAAA case. - - o Changed the section title of "delegation loop" to "lame - delegation" in order to reflect the essential point of the issue. - Wording on this matter was updated accordingly. - - o Updated the Acknowledgements list. - - o Changed the reference category from normative to informative (this - is an informational document after all). - - o Changed the draft name to an IETF dnsop working group document (as - agreed). - - o Applied several editorial fixes. - - - - - - - - - - - - - - - - - - - - - - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 7] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Morishita & Jinmei Expires July 11, 2004 [Page 8] - -Internet-Draft Common Misbehavior against AAAA Queries January 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Morishita & Jinmei Expires July 11, 2004 [Page 9] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt deleted file mode 100644 index f6ece88210345..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-01.txt +++ /dev/null @@ -1,485 +0,0 @@ - DNSOP Working Group Paul Vixie, ISC (Ed.) - INTERNET-DRAFT Akira Kato, WIDE - <draft-ietf-dnsop-respsize-01.txt> July, 2004 - - - DNS Response Size Issues - - - Status of this Memo - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which we are aware have been or will be disclosed, and any of which - we become aware will be disclosed, in accordance with RFC 3668. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - Copyright Notice - - - Copyright (C) The Internet Society (2003-2004). All Rights Reserved. - - - - - - Abstract - - - With a mandated default minimum maximum message size of 512 octets, - the DNS protocol presents some special problems for zones wishing to - expose a moderate or high number of authority servers (NS RRs). This - document explains the operational issues caused by, or related to - this response size limit. - - - - - - - Expires December 2004 [Page 1] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 1 - Introduction and Overview - - - 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512 - octets. Even though this limitation was due to the required minimum UDP - reassembly limit for IPv4, it is a hard DNS protocol limit and is not - implicitly relaxed by changes in transport, for example to IPv6. - - - 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger - responses by mutual agreement of the requestor and responder. However, - deployment of EDNS0 cannot be expected to reach every Internet resolver - in the short or medium term. The 512 octet message size limit remains - in practical effect at this time. - - - 1.3. Since DNS responses include a copy of the request, the space - available for response data is somewhat less than the full 512 octets. - For negative responses, there is rarely a space constraint. For - positive and delegation responses, though, every octet must be carefully - and sparingly allocated. This document specifically addresses - delegation response sizes. - - - 2 - Delegation Details - - - 2.1. A delegation response will include the following elements: - - - Header Section: fixed length (12 octets) - Question Section: original query (name, class, type) - Answer Section: (empty) - Authority Section: NS RRset (nameserver names) - Additional Section: A and AAAA RRsets (nameserver addresses) - - - 2.2. If the total response size would exceed 512 octets, and if the data - that would not fit was in the question, answer, or authority section, - then the TC bit will be set (indicating truncation) which may cause the - requestor to retry using TCP, depending on what information was present - and what was omitted. If a retry using TCP is needed, the total cost of - the transaction is much higher. - - - 2.3. RRsets are never sent partially, so if truncation occurs, entire - RRsets are omitted. Note that the authority section consists of a - single RRset. It is absolutely essential that truncation not occur in - the authority section. - - - - - - - - - Expires December 2004 [Page 2] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 2.4. DNS label compression allows a domain name to be instantiated only - once per DNS message, and then referenced with a two-octet "pointer" - from other locations in that same DNS message. If all nameserver names - in a message are similar (for example, all ending in ".ROOT- - SERVERS.NET"), then more space will be available for uncompressable data - (such as nameserver addresses). - - - 2.5. The query name can be as long as 255 characters of presentation - data, which can be up to 256 octets of network data. In this worst case - scenario, the question section will be 260 octets in size, which would - leave only 240 octets for the authority and additional sections (after - deducting 12 octets for the fixed length header.) - - - 2.6. Average and maximum question section sizes can be predicted by the - zone owner, since they will know what names actually exist, and can - measure which ones are queried for most often. For cost and performance - reasons, the majority of requests should be satisfied without truncation - or TCP retry. - - - 2.7. Requestors who deliberately send large queries to force truncation - are only increasing their own costs, and cannot effectively attack the - resources of an authority server since the requestor would have to retry - using TCP to complete the attack. An attack that always used TCP would - have a lower cost. - - - 2.8. The minimum useful number of address records is two, since with - only one address, the probability that it would refer to an unreachable - server is too high. Truncation which occurs after two address records - have been added to the additional data section is therefore less - operationally significant than truncation which occurs earlier. - - - 2.9. The best case is no truncation. (This is because many requestors - will retry using TCP by reflex, without considering whether the omitted - data was actually necessary.) - - - - - - - - - - - - - - - - Expires December 2004 [Page 3] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 3 - Analysis - - - 3.1. An instrumented protocol trace of a best case delegation response - follows. Note that 13 servers are named, and 13 addresses are given. - This query was artificially designed to exactly reach the 512 octet - limit. - - - ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13 - ;; QUERY SECTION: - ;; [23456789.123456789.123456789.\ - 123456789.123456789.123456789.com A IN] ;; @80 - - - ;; AUTHORITY SECTION: - com. 86400 NS E.GTLD-SERVERS.NET. ;; @112 - com. 86400 NS F.GTLD-SERVERS.NET. ;; @128 - com. 86400 NS G.GTLD-SERVERS.NET. ;; @144 - com. 86400 NS H.GTLD-SERVERS.NET. ;; @160 - com. 86400 NS I.GTLD-SERVERS.NET. ;; @176 - com. 86400 NS J.GTLD-SERVERS.NET. ;; @192 - com. 86400 NS K.GTLD-SERVERS.NET. ;; @208 - com. 86400 NS L.GTLD-SERVERS.NET. ;; @224 - com. 86400 NS M.GTLD-SERVERS.NET. ;; @240 - com. 86400 NS A.GTLD-SERVERS.NET. ;; @256 - com. 86400 NS B.GTLD-SERVERS.NET. ;; @272 - com. 86400 NS C.GTLD-SERVERS.NET. ;; @288 - com. 86400 NS D.GTLD-SERVERS.NET. ;; @304 - - - ;; ADDITIONAL SECTION: - A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320 - B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336 - C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352 - D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368 - E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384 - F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400 - G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416 - H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432 - I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448 - J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464 - K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480 - L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496 - M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512 - - - ;; MSG SIZE sent: 80 rcvd: 512 - - - - - - - Expires December 2004 [Page 4] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 3.2. For longer query names, the number of address records supplied will - be lower. Furthermore, it is only by using a common parent name (which - is GTLD-SERVERS.NET in this example) that all 13 addresses are able to - fit. The following output from a response simulator demonstrates these - properties: - - - % perl respsize.pl 13 13 0 - common name, average case: msg:303 nsaddr#13 (green) - common name, worst case: msg:495 nsaddr# 1 (red) - uncommon name, average case: msg:457 nsaddr# 3 (orange) - uncommon name, worst case: msg:649(*) nsaddr# 0 (red) - % perl respsize.pl 13 13 2 - common name, average case: msg:303 nsaddr#11 (orange) - common name, worst case: msg:495 nsaddr# 1 (red) - uncommon name, average case: msg:457 nsaddr# 2 (orange) - uncommon name, worst case: msg:649(*) nsaddr# 0 (red) - - - (Note: The response simulator program is shown in Section 5.) - - - Here we use the term "green" if all address records could fit, or - "orange" if two or more could fit, or "red" if fewer than two could fit. - It's clear that without a common parent for nameserver names, much space - would be lost. - - - We're assuming an average query name size of 64 since that is the - typical average maximum size seen in trace data at the time of this - writing. If Internationalized Domain Name (IDN) or any other technology - which results in larger query names be deployed significantly in advance - of EDNS, then more new measurements and new estimates will have to be - made. - - - 4 - Conclusions - - - 4.1. The current practice of giving all nameserver names a common parent - (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS - responses and allows for more nameservers to be enumerated than would - otherwise be possible. (Note that in this case it is wise to serve the - common parent domain's zone from the same servers that are named within - it, in order to limit external dependencies when all your eggs are in a - single basket.) - - - 4.2. Thirteen (13) seems to be the effective maximum number of - nameserver names usable traditional (non-extended) DNS, assuming a - common parent domain name, and assuming that additional-data truncation - is undesirable in the average case. - - - - - Expires December 2004 [Page 5] - INTERNET-DRAFT June 2003 RESPSIZE - - - - 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a - prototypical delegation that currently contains thirteen (13) IPv4 - nameserver addresses (A RRs) for thirteen (13) nameserver names under a - common parent, would not have a significant negative operational impact - on the domain name system. - - - 5 - Source Code - - - #!/usr/bin/perl -w - - - $asize = 2+2+2+4+2+4; - $aaaasize = 2+2+2+4+2+16; - ($nns, $na, $naaaa) = @ARGV; - test("common", "average", common_name_average($nns), - $na, $naaaa); - test("common", "worst", common_name_worst($nns), - $na, $naaaa); - test("uncommon", "average", uncommon_name_average($nns), - $na, $naaaa); - test("uncommon", "worst", uncommon_name_worst($nns), - $na, $naaaa); - exit 0; - - - sub test { my ($namekind, $casekind, $msg, $na, $naaaa) = @_; - my $nglue = numglue($msg, $na, $naaaa); - printf "%8s name, %7s case: msg:%3d%s nsaddr#%2d (%s)\n", - $namekind, $casekind, - $msg, ($msg > 512) ? "(*)" : " ", - $nglue, ($nglue == $na + $naaaa) ? "green" - : ($nglue >= 2) ? "orange" - : "red"; - } - - - sub pnum { my ($num, $tot) = @_; - return sprintf "%3d%s", - } - - - sub numglue { my ($msg, $na, $naaaa) = @_; - my $space = ($msg > 512) ? 0 : (512 - $msg); - my $num = 0; - - - while ($space && ($na || $naaaa )) { - if ($na) { - if ($space >= $asize) { - $space -= $asize; - - - - - Expires December 2004 [Page 6] - INTERNET-DRAFT June 2003 RESPSIZE - - - - $num++; - } - $na--; - } - if ($naaaa) { - if ($space >= $aaaasize) { - $space -= $aaaasize; - $num++; - } - $naaaa--; - } - } - return $num; - } - - - sub msgsize { my ($qname, $nns, $nsns) = @_; - return 12 + # header - $qname+2+2 + # query - 0 + # answer - $nns * (4+2+2+4+2+$nsns); # authority - } - - - sub average_case { my ($nns, $nsns) = @_; - return msgsize(64, $nns, $nsns); - } - - - sub worst_case { my ($nns, $nsns) = @_; - return msgsize(256, $nns, $nsns); - } - - - sub common_name_average { my ($nns) = @_; - return 15 + average_case($nns, 2); - } - - - sub common_name_worst { my ($nns) = @_; - return 15 + worst_case($nns, 2); - } - - - sub uncommon_name_average { my ($nns) = @_; - return average_case($nns, 15); - } - - - sub uncommon_name_worst { my ($nns) = @_; - return worst_case($nns, 15); - } - - - - - Expires December 2004 [Page 7] - INTERNET-DRAFT June 2003 RESPSIZE - - - - Security Considerations - - - The recommendations contained in this document have no known security - implications. - - - IANA Considerations - - - This document does not call for changes or additions to any IANA - registry. - - - IPR Statement - - - Copyright (C) The Internet Society (2003-2004). This document is - subject to the rights, licenses and restrictions contained in BCP 78, - and except as set forth therein, the authors retain all their rights. - - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR - IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - - Authors' Addresses - - - Paul Vixie - 950 Charter Street - Redwood City, CA 94063 - +1 650 423 1301 - vixie@isc.org - - - Akira Kato - University of Tokyo, Information Technology Center - 2-11-16 Yayoi Bunkyo - Tokyo 113-8658, JAPAN - +81 3 5841 2750 - kato@wide.ad.jp - - - - - - - - - - - Expires December 2004 [Page 8]
\ No newline at end of file diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt deleted file mode 100644 index b593c57179e33..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-02.txt +++ /dev/null @@ -1,617 +0,0 @@ - - -Network Working Group S. Woolf -Internet-Draft Internet Systems Consortium, Inc. -Expires: January 16, 2005 D. Conrad - Nominum, Inc. - July 18, 2004 - - - Identifying an Authoritative Name `Server - draft-ietf-dnsop-serverid-02 - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667. By submitting this Internet-Draft, each - author represents that any applicable patent or other IPR claims of - which he or she is aware have been or will be disclosed, and any of - which he or she become aware will be disclosed, in accordance with - RFC 3668. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 16, 2005. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid. Existing ad - - - -Woolf & Conrad Expires January 16, 2005 [Page 1] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - - hoc mechanisms for addressing this concern are not adequate. This - document attempts to describe the common ad hoc solution to this - problem, including its advantages and disadvantasges, and to - characterize an improved mechanism. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 2] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -1. Introduction - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid. - - Unfortunately, existing ad-hoc mechanisms for providing such - identification have some shortcomings, not the least of which is the - lack of prior analysis of exactly how such a mechanism should be - designed and deployed. This document describes the existing - convention used in one widely deployed implementation of the DNS - protocol and discusses requirements for an improved solution to the - problem. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 3] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -2. Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. However, relying on the IP address of the name server - has become more problematic due the deployment of various load - balancing solutions, including the use of shared unicast addresses as - documented in [RFC3258]. - - An unfortunate side effect of these load balancing solutions is that - traditional methods of determining which server is responding can be - unreliable. Specifically, non-DNS methods such as ICMP ping, TCP - connections, or non-DNS UDP packets (e.g., as generated by tools such - as "traceroute"), etc., can end up going to a different server than - that which receives the DNS queries. - - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 4] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -3. Existing Conventions - - Recent versions of the commonly deployed Berkeley Internet Name - Domain implementation of the DNS protocol suite from the Internet - Software Consortium [BIND] support a way of identifying a particular - server via the use of a standard, if somewhat unusual, DNS query. - Specifically, a query to a late model BIND server for a TXT resource - record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will - return a string that can be configured by the name server - administrator to provide a unique identifier for the responding - server (defaulting to the value of a gethostname() call). This - mechanism, which is an extension of the BIND convention of using - CHAOS class TXT RR queries to sub-domains of the "BIND." domain for - version information, has been copied by several name server vendors. - - For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A - query for a TXT RR for this name will return an administratively re- - definable string which defaults to the version of the server - responding. - -3.1 Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - 1. This mechanism is within the DNS protocol itself. An - identification mechanism that relies on the DNS protocol is more - likely to be successful (although not guaranteed) in going to the - same machine as a "normal" DNS query. - 2. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - 3. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - -3.2 Disadvantages - - At the same time, there are some forbidding drawbacks to the - VERSION.BIND mechanism that argue against standardizing it as it - currently operates. - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - - - -Woolf & Conrad Expires January 16, 2005 [Page 5] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - - purpose is a good use of the namespace or of implementation - effort. - 3. It is implementation specific. BIND is one DNS implementation. - At the time of this writing, it is probably the most prevalent, - for authoritative servers anyway. This does not justify - standardizing on its ad hoc solution to a problem shared across - many operators and implementors. - - The first of the listed disadvantages is technically the most - serious. It argues for an attempt to design a good answer to the - problem that "I need to know what nameserver is answering my - queries", not simply a convenient one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 6] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -4. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - HOSTNAME.BIND mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - 1. The mechanism adopted MUST be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It SHOULD - also permit a separate, dedicated query for the server's - identifying information. - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e. the OPT pseudo-RR. - 3. Support for the identification functionality SHOULD be easy to - implement and easy to enable. It MUST be easy to disable and - SHOULD lend itself to access controls on who can query for it. - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be - non-public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - 5. The identification mechanism SHOULD NOT be - implementation-specific. - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 7] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -5. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. Should such extensions be specified and adopted by normal - IETF process, the specification will include appropriate guidance to - IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 8] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -6. Security Considerations - - Providing identifying information as to which server is responding - can be seen as information leakage and thus a security risk. This - motivates the suggestion above that a new mechanism for server - identification allow the administrator to disable the functionality - altogether or partially restrict availability of the data. It also - suggests that the serverid data should not be readily correlated with - a hostname or unicast IP address that may be considered private to - the nameserver operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 9] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -7. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier drafts were provided by Bob Halley, Brian Wellington, Andreas - Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the - ICANN Root Server System Advisory Committee. The newest draft takes - a significantly different direction from previous versions, owing to - discussion among contributors to the DNSOP working group and others, - particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam Weiler, - and Rob Austein. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Expires January 16, 2005 [Page 10] - -Internet-Draft Identifying an Authoritative Name `Server July 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2004). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Woolf & Conrad Expires January 16, 2005 [Page 11] - - diff --git a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt deleted file mode 100644 index 3353b3bb423f3..0000000000000 --- 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-ipseckey-rr-09.txt b/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt deleted file mode 100644 index 423a119f39f8b..0000000000000 --- a/contrib/bind9/doc/draft/draft-ietf-ipseckey-rr-09.txt +++ /dev/null @@ -1,951 +0,0 @@ - - -IPSECKEY WG M. Richardson -Internet-Draft SSW -|Expires: August 1, 2004 February 2004 - - - A Method for Storing IPsec Keying Material in DNS -| draft-ietf-ipseckey-rr-09.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -| This Internet-Draft will expire on August 1, 2004. - -Copyright Notice - -| Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - -| This document describes a new resource record for Domain Name System -| (DNS). This record may be used to store public keys for use in IP -| security (IPsec) systems. The record also includes provisions for -| indicating what system should be contacted when establishing an IPsec -| tunnel with the entity in question. - - This record replaces the functionality of the sub-type #1 of the KEY - Resource Record, which has been obsoleted by RFC3445. - - - - - - - -|Richardson Expires August 1, 2004 [Page 1] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 -| 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3 -| 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 -| 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 5 -| 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5 -| 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5 -| 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5 -| 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 6 -| 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6 -| 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 6 -| 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 8 -| 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 8 -| 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 -| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 -| 4.1 Active attacks against unsecured IPSECKEY resource records . . 10 -| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 -| 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13 -| 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 -| Normative references . . . . . . . . . . . . . . . . . . . . . 15 -| Non-normative references . . . . . . . . . . . . . . . . . . . 16 -| Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 -| Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 2] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -1. Introduction - - It postulated that there is an end system desiring to establish an - IPsec tunnel with some remote entity on the network. This system, - having only a DNS name of some kind (forward, reverse or even - user@FQDN) needs a public key to authenticate the remote entity. It - also desires some guidance about whether to contact the entity - directly, or whether to contact another entity, as the gateway to - that desired entity. - - The IPSECKEY RR provides a storage mechanism for such items as the - public key, and the gateway information. - - The type number for the IPSECKEY RR is TBD. - -1.1 Overview - - The IPSECKEY resource record (RR) is used to publish a public key - that is to be associated with a Domain Name System (DNS) name for use - with the IPsec protocol suite. This can be the public key of a - host, network, or application (in the case of per-port keying). - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 [7]. - -|1.2 Use of reverse (in-addr.arpa) map - -| Often a security gateway will only have access to the IP address to -| which communication is desired. It will not know the forward name. -| As such, it will frequently be the case that the IP address will be -| used an index into the reverse map. - -| The lookup is done in the usual fashion as for PTR records. The IP -| address' octets (IPv4) or nibbles (IPv6) are reversed and looked up -| under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be -| followed. - -| Note: even when the IPsec function is the end-host, often only the -| application will know the forward name used. While the case where -| the application knows the forward name is common, the user could -| easily have typed in a literal IP address. This storage mechanism -| does not preclude using the forward name when it is available, but -| does not require it. - -|1.3 Usage Criteria - - An IPSECKEY resource record SHOULD be used in combination with DNSSEC - - - -|Richardson Expires August 1, 2004 [Page 3] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - unless some other means of authenticating the IPSECKEY resource - record is available. - - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence of - multiple gateways and the need to rollover keys. - - This resource record is class independent. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 4] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -2. Storage formats - -2.1 IPSECKEY RDATA format - - The RDATA for an IPSECKEY RR consists of a precedence value, a - gateway type, a public key, algorithm type, and an optional gateway - address. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - -2.2 RDATA format - precedence - - This is an 8-bit precedence for this record. This is interpreted in - the same way as the PREFERENCE field described in section 3.3.9 of - RFC1035 [2]. - - Gateways listed in IPSECKEY records with lower precedence are to be - attempted first. Where there is a tie in precedence, the order - should be non-deterministic. - -2.3 RDATA format - gateway type - - The gateway type field indicates the format of the information that - is stored in the gateway field. - - The following values are defined: - - 0 No gateway is present - - 1 A 4-byte IPv4 address is present - - 2 A 16-byte IPv6 address is present - - 3 A wire-encoded domain name is present. The wire-encoded format is - self-describing, so the length is implicit. The domain name MUST - NOT be compressed. (see section 3.3 of RFC1035 [2]). - - - - -|Richardson Expires August 1, 2004 [Page 5] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -2.4 RDATA format - algorithm type - - The algorithm type field identifies the public key's cryptographic - algorithm and determines the format of the public key field. - - A value of 0 indicates that no key is present. - - The following values are defined: - - 1 A DSA key is present, in the format defined in RFC2536 [10] - - 2 A RSA key is present, in the format defined in RFC3110 [11] - - -2.5 RDATA format - gateway - - The gateway field indicates a gateway to which an IPsec tunnel may be - created in order to reach the entity named by this resource record. - - There are three formats: - - A 32-bit IPv4 address is present in the gateway field. The data - portion is an IPv4 address as described in section 3.4.1 of RFC1035 - [2]. This is a 32-bit number in network byte order. - - A 128-bit IPv6 address is present in the gateway field. The data - portion is an IPv6 address as described in section 2.2 of RFC3596 - [13]. This is a 128-bit number in network byte order. - - The gateway field is a normal wire-encoded domain name, as described - in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. - -2.6 RDATA format - public keys - - Both of the public key types defined in this document (RSA and DSA) - inherit their public key formats from the corresponding KEY RR - formats. Specifically, the public key field contains the algorithm- - specific portion of the KEY RR RDATA, which is all of the KEY RR DATA - after the first four octets. This is the same portion of the KEY RR - that must be specified by documents that define a DNSSEC algorithm. - Those documents also specify a message digest to be used for - generation of SIG RRs; that specification is not relevant for - IPSECKEY RR. - - Future algorithms, if they are to be used by both DNSSEC (in the KEY - RR) and IPSECKEY, are likely to use the same public key encodings in - both records. Unless otherwise specified, the IPSECKEY public key - field will contain the algorithm-specific portion of the KEY RR RDATA - - - -|Richardson Expires August 1, 2004 [Page 6] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - for the corresponding algorithm. The algorithm must still be - designated for use by IPSECKEY, and an IPSECKEY algorithm type number - (which might be different than the DNSSEC algorithm number) must be - assigned to it. - - The DSA key format is defined in RFC2536 [10] - - The RSA key format is defined in RFC3110 [11], with the following - changes: - - The earlier definition of RSA/MD5 in RFC2065 limited the exponent and - modulus to 2552 bits in length. RFC3110 extended that limit to 4096 - bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on - RSA public keys, other than the 65535 octet limit imposed by the two- - octet length encoding. This length extension is applicable only to - IPSECKEY and not to KEY RRs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 7] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -3. Presentation formats - -3.1 Representation of IPSECKEY RRs - - IPSECKEY RRs may appear in a zone data master file. The precedence, - gateway type and algorithm and gateway fields are REQUIRED. The - base64 encoded public key block is OPTIONAL; if not present, then the - public key field of the resource record MUST be construed as being - zero octets in length. - - The algorithm field is an unsigned integer. No mnemonics are - defined. - - If no gateway is to be indicated, then the gateway type field MUST be - zero, and the gateway field MUST be "." - - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see RFC3548 [6] Section 5.2. - - The general presentation for the record as as follows: - - IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) - - -3.2 Examples - - An example of a node 192.0.2.38 that will accept IPsec tunnels on its - own behalf. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has published its key only. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has delegated authority to the - node 192.0.2.3. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - -|Richardson Expires August 1, 2004 [Page 8] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - An example of a node, 192.0.1.38 that has delegated authority to the - node with the identity "mygateway.example.com". - - 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has - delegated authority to the node 2001:0DB8:c000:0200:2::1 - - $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. - 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 9] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -4. Security Considerations - - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. - - The IPSECKEY resource record contains information that SHOULD be - communicated to the end client in an integral fashion - i.e. free - from modification. The form of this channel is up to the consumer of - the data - there must be a trust relationship between the end - consumer of this resource record and the server. This relationship - may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to - another secure source, a secure local channel on the host, or some - combination of the above. - - The keying material provided by the IPSECKEY resource record is not - sensitive to passive attacks. The keying material may be freely - disclosed to any party without any impact on the security properties - of the resulting IPsec session: IPsec and IKE provide for defense - against both active and passive attacks. - - Any derivative standard that makes use of this resource record MUST - carefully document their trust model, and why the trust model of - DNSSEC is appropriate, if that is the secure channel used. - -4.1 Active attacks against unsecured IPSECKEY resource records - - This section deals with active attacks against the DNS. These - attacks require that DNS requests and responses be intercepted and - changed. DNSSEC is designed to defend against attacks of this kind. - - The first kind of active attack is when the attacker replaces the - keying material with either a key under its control or with garbage. - - If the attacker is not able to mount a subsequent man-in-the-middle - attack on the IKE negotiation after replacing the public key, then - this will result in a denial of service, as the authenticator used by - IKE would fail. - - If the attacker is able to both to mount active attacks against DNS - and is also in a position to perform a man-in-the-middle attack on - IKE and IPsec negotiations, then the attacker will be in a position - to compromise the resulting IPsec channel. Note that an attacker - must be able to perform active DNS attacks on both sides of the IKE - negotiation in order for this to succeed. - - The second kind of active attack is one in which the attacker - replaces the the gateway address to point to a node under the - attacker's control. The attacker can then either replace the public - - - -|Richardson Expires August 1, 2004 [Page 10] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - - key or remove it, thus providing an IPSECKEY record of its own to - match the gateway address. - - This later form creates a simple man-in-the-middle since the attacker - can then create a second tunnel to the real destination. Note that, - as before, this requires that the attacker also mount an active - attack against the responder. - - Note that the man-in-the-middle can not just forward cleartext - packets to the original destination. While the destination may be - willing to speak in the clear, replying to the original sender, the - sender will have already created a policy expecting ciphertext. - Thus, the attacker will need to intercept traffic from both sides. - In some cases, the attacker may be able to accomplish the full - intercept by use of Network Addresss/Port Translation (NAT/NAPT) - technology. - -| Note that risk of a man-in-the-middle attack mediated by the IPSECKEY -| RR only applies to cases where the gateway field of the IPSECKEY RR -| indicates a different entity than the owner name of the IPSECKEY RR. - -| An active attack on the DNS that caused the wrong IP address to be -| retrieved (via forged A RR), and therefore the wrong QNAME to be -| queried would also result in a man-in-the-middle attack. This -| situation exists independantly of whether or not the IPSECKEY RR is -| used. - -| In cases where the end-to-end integrity of the IPSECKEY RR is -| suspect, the end client MUST restrict its use of the IPSECKEY RR to -| cases where the RR owner name matches the content of the gateway -| field. - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 11] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -5. IANA Considerations - - This document updates the IANA Registry for DNS Resource Record Types - by assigning type X to the IPSECKEY record. - - This document creates two new IANA registries, both specific to the - IPSECKEY Resource Record: - - This document creates an IANA registry for the algorithm type field. - - Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 - through 255 can be assigned by IETF Consensus (see RFC2434 [5]). - - This document creates an IANA registry for the gateway type field. - - Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type - numbers 4 through 255 can be assigned by Standards Action (see - RFC2434 [5]). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 12] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -6. Intellectual Property Claims - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 13] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -7. Acknowledgments - - My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob - Austein, and Olafur Gurmundsson who reviewed this document carefully. - Additional thanks to Olafur Gurmundsson for a reference - implementation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 14] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Normative references - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - [4] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", - RFC 3548, July 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 15] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Non-normative references - - [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [8] Piper, D., "The Internet IP Security Domain of Interpretation - for ISAKMP", RFC 2407, November 1998. - - [9] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS - Extensions to Support IP Version 6", RFC 3596, October 2003. - - -Author's Address - - Michael C. Richardson - Sandelman Software Works - 470 Dawson Avenue - Ottawa, ON K1Z 5V7 - CA - - EMail: mcr@sandelman.ottawa.on.ca - URI: http://www.sandelman.ottawa.on.ca/ - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 16] - -|Internet-Draft Storing IPsec keying material in DNS February 2004 - - -Full Copyright Statement - -| Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -|Richardson Expires August 1, 2004 [Page 17] 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 2d5c87eb3caa8..0000000000000 --- 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 a272d81b0a608..0000000000000 --- 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 3578d2a15eb86..0000000000000 --- 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 d857cd95806bd..0000000000000 --- 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 f9eaf268194f7..0000000000000 --- 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 6ac20904ab20f..0000000000000 --- 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 |