From: Mark Andrews Date: Fri, 14 Mar 2003 18:10:33 +0000 (+0000) Subject: new draft X-Git-Tag: v9.2.3rc1~104^2~70 X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=365ca3501427179f8e4df6e0f2a14cc010637ef1;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-00.txt b/doc/draft/draft-baba-dnsext-acl-reqts-00.txt new file mode 100644 index 00000000000..950e34c7511 --- /dev/null +++ b/doc/draft/draft-baba-dnsext-acl-reqts-00.txt @@ -0,0 +1,336 @@ + + + + +Internet-Draft T. Baba +Expires: August 4, 2003 NTT Data + February 4, 2003 + + + Requirements for Access Control in Domain Name Systems + draft-baba-dnsext-acl-reqts-00.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 August 4, 2003. + +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 August 4, 2003 [Page 1] + +Internet-Draft DNS Access Control Requirements February 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. 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. + + RRset + All resource records (RRs) having the same NAME, CLASS and TYPE + are called a Resource Record Set (RRset). + + + + +Baba Expires August 4, 2003 [Page 2] + +Internet-Draft DNS Access Control Requirements February 2003 + + +3. Requirements + + This section describes the requirements for access control in DNS. + +3.1 Authentication + +3.1.1 Client Identifier / 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. + +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. + + + + + + +Baba Expires August 4, 2003 [Page 3] + +Internet-Draft DNS Access Control Requirements February 2003 + + +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. Although IPsec can be used to encrypt DNS packets, it + authenticates a peer based on IP address. Currently, no encryption + mechanism is specified in DNS. Therefore, new RRs must be defined + for DNS message encryption. In case encryption is applied, entire + DNS message including DNS header must be encrypted to hide + information including error code. + + Query encryption may be also provided. + +3.2.2 Key Exchange + + If DNS message encryption is provided, automatic key exchange + mechanism must 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 August 4, 2003 [Page 4] + +Internet-Draft DNS Access Control Requirements February 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 August 4, 2003 [Page 5] + +Internet-Draft DNS Access Control Requirements February 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. + + [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. + + [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. + + +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 August 4, 2003 [Page 6] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-04.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt similarity index 54% rename from doc/draft/draft-ietf-dnsext-dnssec-opt-in-04.txt rename to doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt index a4309eeaa59..1bfb560cd13 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-04.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-05.txt @@ -1,15 +1,15 @@ -Network Working Group R. Arends -Internet-Draft -Expires: May 2, 2003 M. Kosters +DNSEXT R. Arends +Internet-Draft Telematica Instituut +Expires: August 28, 2003 M. Kosters D. Blacka Verisign, Inc. - November 1, 2002 + February 27, 2003 DNSSEC Opt-In - draft-ietf-dnsext-dnssec-opt-in-04 + draft-ietf-dnsext-dnssec-opt-in-05 Status of this Memo @@ -17,26 +17,25 @@ Status of this Memo 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. + 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 + 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 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 May 2, 2003. + This Internet-Draft will expire on August 28, 2003. Copyright Notice - Copyright (C) The Internet Society (2002). All Rights Reserved. + Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract @@ -52,9 +51,10 @@ Abstract -Arends, et al. Expires May 2, 2003 [Page 1] + +Arends, et al. Expires August 28, 2003 [Page 1] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 Table of Contents @@ -66,23 +66,24 @@ Table of Contents 3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6 3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6 + 3.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7 3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7 3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8 3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8 - 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 12 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 13 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 - References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 - A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 18 - B. Changes from Prior Versions . . . . . . . . . . . . . . . . 20 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 21 - + 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 13 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 + Normative References . . . . . . . . . . . . . . . . . . . . 18 + Informative References . . . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 + A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 21 + B. Changes from Prior Versions . . . . . . . . . . . . . . . . 23 + Intellectual Property and Copyright Statements . . . . . . . 25 @@ -107,28 +108,33 @@ Table of Contents - -Arends, et al. Expires May 2, 2003 [Page 2] +Arends, et al. Expires August 28, 2003 [Page 2] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 1. Definitions and Terminology Throughout this document, familiarity with the DNS system, RFC 1035 - [1], DNS security extensions, RFC 2535 [4], and DNSSEC terminology - RFC 3090 [5] is assumed. + [1], DNS security extensions, RFC 2535 [2], and DNSSEC terminology + RFC 3090 [8] is assumed. The following abbreviations and terms are used in this document: RR: is used to refer to a DNS resource record. - RRset: refers to a Resource Record Set, as defined by [3]. In this + RRset: refers to a Resource Record Set, as defined by [6]. In this document, the RRset is also defined to include the covering SIG records, if any exist. + signed name: refers to a DNS name that has, at minimum, a (signed) + NXT record. + + unsigned name: refers to a DNS name that does not (at least) have a + NXT record. + covering NXT record/RRset: is the NXT record used to prove - (non)existence of a particular name or RRset. This means that for + (non)existence of a particular name or RRset. This means that for a RRset or name 'N', the covering NXT record has the name 'N', or has an owner name less than 'N' and "next" name greater than 'N'. @@ -136,26 +142,21 @@ Internet-Draft DNSSEC Opt-In November 2002 current zone apex (non-zone-apex), signifying a delegation to a subzone. - secure delegation: refers to the NS, DS, NXT and SIG RRsets for a - non-zone-apex owner name, signifying a delegation to a DNSSEC + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a signed subzone. - 2535/DS insecure delegation: refers to the NS, NXT, and SIG RRsets - for a non-zone-apex owner name, signifying a delegation to an - unsigned subzone. This differs from the secured delegation by the - absence of a DS RRset, marked by the zero value for the DS type - code in the NXT type map. + 2535/DS insecure delegation: refers to a signed name containing a + delegation (NS RRset), but lacking a DS RRset, signifying a + delegation to an unsigned subzone. - Opt-In insecure delegation: refers to the NS RRset for a non-zone- - apex owner name where the covering NXT record uses the Opt-In - methodology described in this document. + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NXT record uses the + Opt-In methodology described in this document. The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [2]. - - - + document are to be interpreted as described in RFC 2119 [5]. @@ -163,10 +164,9 @@ Internet-Draft DNSSEC Opt-In November 2002 - -Arends, et al. Expires May 2, 2003 [Page 3] +Arends, et al. Expires August 28, 2003 [Page 3] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 2. Overview @@ -220,16 +220,16 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 4] +Arends, et al. Expires August 28, 2003 [Page 4] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 3. Protocol Additions - In RFC 2535, delegation NS RRsets are not signed, but instead are - accompanied by a NXT RRset of the same name, and possibly a ("no- - key") KEY RR [4] or DS record [7]. The security status of the + In RFC 2535, delegation NS RRsets are not signed, but are instead + accompanied by a NXT RRset of the same name, and possibly a + ("no-key") KEY RR [2] or DS record [3]. The security status of the subzone is determined by the presence of the KEY or DS records, cryptographically proven by the NXT record. Opt-In expands this definition by allowing insecure delegations to exist within an @@ -246,41 +246,46 @@ Internet-Draft DNSSEC Opt-In November 2002 the record itself, this bit is redundant and safe for use as a tag. An Opt-In tagged NXT record does not assert the (non)existence of the - delegations that it covers. This allows for the addition or removal - of these delegations without recalculating the resigning the NXT - chain. However, Opt-In tagged NXT records do assert the - (non)existence of other signed RRsets. + delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning the NXT chain. However, Opt-In + tagged NXT records do assert the (non)existence of other RRsets. + + An Opt-In NXT record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in type map, or the presence of a "no-key" KEY + RRset, and the NXT record does assert the existence of the + delegation. Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records and RFC 2535 NXT records. If a NXT record is not Opt-In, there MUST - NOT be any insecure delegations between it and the RRsets indicated - by the 'next domain name' in the NXT RDATA. If it is Opt-In, there - MUST only be insecure delegations between it and the next node - indicated by the 'next domain name' in the NXT RDATA. + NOT be any insecure delegations (or any other records) between it and + the RRsets indicated by the 'next domain name' in the NXT RDATA. If + it is Opt-In, there MUST only be insecure delegations between it and + the next node indicated by the 'next domain name' in the NXT RDATA. In summary, - o An Opt-In NXT type is identified by a zero-valued (or not- - specified) NXT bit in the type bit map of the NXT record. + o An Opt-In NXT type is identified by a zero-valued (or + not-specified) NXT bit in the type bit map of the NXT record. o A RFC2535 NXT type is identified by a one-valued NXT bit in the type bit map of the NXT record. and, - o An Opt-In NXT record does not assert the non-existence of a name - between its owner name and "next" name, although it does assert - that any name in this span MUST be an insecure delegation. - - o An Opt-In NXT record does assert the (non)existence of RRsets with - -Arends, et al. Expires May 2, 2003 [Page 5] +Arends, et al. Expires August 28, 2003 [Page 5] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 + o An Opt-In NXT record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + + o An Opt-In NXT record does assert the (non)existence of RRsets with the same owner name. @@ -292,7 +297,9 @@ Internet-Draft DNSSEC Opt-In November 2002 This specification dictates that only insecure delegations may exist between the owner and "next" names of an Opt-In tagged NXT record. - Servers and signing tools MUST enforce this restriction. + Signing tools SHOULD NOT generate signed zones that violate this + restriction. Servers SHOULD refuse to load and/or serve zones that + violate this restriction. 3.1.2 Insecure Delegation Responses @@ -310,42 +317,42 @@ Internet-Draft DNSSEC Opt-In November 2002 3.1.3 Wildcards and Opt-In RFC 2535, in section 5.3, describes the practice of returning NXT - records to prove the non-existence of an applicable wildcard in non- - existent name responses. This NXT record can be described as a - "negative wildcard proof". The use of Opt-In NXT records changes the - necessity for this practice. For non-existent name (NXDOMAIN) - responses when the query name (qname) is covered by an Opt-In tagged - NXT record, servers MUST NOT return negative wildcard proof records. + records to prove the non-existence of an applicable wildcard in + non-existent name responses. This NXT record can be described as a + "negative wildcard proof". The use of Opt-In NXT records changes the + necessity for this practice. For non-existent name responses when the + query name (qname) is covered by an Opt-In tagged NXT record, servers + MAY choose to omit the wildcard proof record, and clients MUST NOT + treat the absence of this NXT record as a validation error. The intent of the RFC 2535 negative wildcard proof requirement is to prevent malicious users from undetectably removing valid wildcard responses. In order for this cryptographic proof to work, the resolver must be able to prove: - 1. The exact qname does not exist. This is done by the "normal" NXT - record. - - 2. No applicable wildcard exists. This is done by returning one or - more NXT records proving that the wildcards do not exist - (negative wildcard proofs). +Arends, et al. Expires August 28, 2003 [Page 6] + +Internet-Draft DNSSEC Opt-In February 2003 -Arends, et al. Expires May 2, 2003 [Page 6] - -Internet-Draft DNSSEC Opt-In November 2002 + 1. The exact qname does not exist. This is done by the "normal" NXT + record. + 2. No applicable wildcard exists. This is done by returning a NXT + record proving that the wildcard does not exist (negative + wildcard proof). However, if the NXT record covering the exact qname is an Opt-In NXT record, the resolver will not be able to prove the first part of this equation, as the qname might exist as an insecure delegation. Thus, since the total proof cannot be completed, the negative wildcard - proof records are not useful. + proof record is not useful. - The negative wildcard proofs are also not useful when returned as - part of an Opt-In insecure delegation response for a similar reason: - the resolver cannot prove that the qname does or does not exist, and + The negative wildcard proof is also not useful when returned as part + of an Opt-In insecure delegation response for a similar reason: the + resolver cannot prove that the qname does or does not exist, and therefore cannot prove that a wildcard expansion is valid. The presence of an Opt-In tagged NXT record does not change the @@ -354,6 +361,15 @@ Internet-Draft DNSSEC Opt-In November 2002 expansion is valid, it will prove that the wildcard expansion is not masking any signed records. +3.1.4 Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [7]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NXT chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NXT records. + 3.2 Client Considerations Opt-In imposes some new requirements on DNS resolvers (caching or @@ -369,6 +385,14 @@ Internet-Draft DNSSEC Opt-In November 2002 3.2.2 Validation Process Changes + + + +Arends, et al. Expires August 28, 2003 [Page 7] + +Internet-Draft DNSSEC Opt-In February 2003 + + This specification does not change the resolver's resolution algorithm. However, it does change the DNSSEC validation process. Resolvers MUST be able to use Opt-In tagged NXT records to @@ -381,17 +405,12 @@ Internet-Draft DNSSEC Opt-In November 2002 RRset indicates that the referred-to zone is secure. o Using Delegation Signer, the security status is proven by the - existence or absence of a DS record at the same name as the - delegation. The absence is proven using a verified NXT record of - the same name that does not have the DS bit set in the type map. - This NXT record MAY also be tagged as Opt-In. - - - -Arends, et al. Expires May 2, 2003 [Page 7] - -Internet-Draft DNSSEC Opt-In November 2002 - + existence or absence of a DS RRset at the same name as the + delegation. The existence of the DS RRset indicates that the + referred-to zone is secure. The absence of the DS RRset is proven + using a verified NXT record of the same name that does not have + the DS bit set in the type map. This NXT record MAY also be + tagged as Opt-In. o Using Opt-In, the security status is proven by the existence of a DS record (for secure) or the presence of a verified Opt-In tagged @@ -419,9 +438,17 @@ Internet-Draft DNSSEC Opt-In November 2002 3.2.4 Use of the AD bit - The AD bit, as defined by [8], MUST NOT be set when: + The AD bit, as defined by [4], MUST NOT be set when: o sending a non-existent name (NXDOMAIN) response where the covering + + + +Arends, et al. Expires August 28, 2003 [Page 8] + +Internet-Draft DNSSEC Opt-In February 2003 + + NXT is tagged as Opt-In. o sending an Opt-In insecure delegation response, unless the @@ -444,9 +471,38 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 8] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 9] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 4. Benefits @@ -456,7 +512,7 @@ Internet-Draft DNSSEC Opt-In November 2002 maintaining the security of the zone. Opt-In accomplishes this by eliminating the need for both "no-key" - KEY (in [4]) and NXT records for insecure delegations. This, in a + KEY (in [2]) and NXT records for insecure delegations. This, in a zone with a large number of delegations to unsigned subzones, can lead to substantial space savings (both in memory and on disk). Additionally, Opt-In allows for the addition or removal of insecure @@ -500,9 +556,9 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 9] +Arends, et al. Expires August 28, 2003 [Page 10] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 5. Example @@ -510,7 +566,7 @@ Internet-Draft DNSSEC Opt-In November 2002 Consider the zone EXAMPLE, shown below. This is a zone where all of the NXT records are tagged as Opt-In. - Example A: Fully Opt-In Zone. + Example A: Fully DS/Opt-In Zone. EXAMPLE. SOA ... EXAMPLE. SIG SOA ... @@ -523,15 +579,19 @@ Internet-Draft DNSSEC Opt-In November 2002 FIRST-SECURE.EXAMPLE. A ... FIRST-SECURE.EXAMPLE. SIG A ... - FIRST-SECURE.EXAMPLE. NXT SECOND-SECURE.EXAMPLE. A SIG + FIRST-SECURE.EXAMPLE. NXT NOT-SECURE-2.EXAMPLE. A SIG FIRST-SECURE.EXAMPLE. SIG NXT ... NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. NS.NOT-SECURE.EXAMPLE. A ... + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NXT SECOND-SECURE.EXAMPLE NS SIG + NOT-SECURE-2.EXAMPLE SIG NXT ... + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. - SECOND-SECURE.EXAMPLE. KEY ... - SECOND-SECURE.EXAMPLE. SIG KEY ... + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. SIG DS ... SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY SECOND-SECURE.EXAMPLE. SIG NXT ... @@ -539,29 +599,29 @@ Internet-Draft DNSSEC Opt-In November 2002 NS.UNSIGNED.EXAMPLE. A ... - In this example, a query for a signed RRset (e.g., "FIRST- - SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND- - SECURE.EXAMPLE A") will result in a standard RFC 2535 response. + In this example, a query for a signed RRset (e.g., + "FIRST-SECURE.EXAMPLE A"), or a secure delegation + ("WWW.SECOND-SECURE.EXAMPLE A") will result in a standard RFC 2535 + response. A query for a nonexistent RRset will result in a response that differs from RFC 2535 by: the NXT record will be tagged as Opt-In, - there will be no NXT record proving the non-existence of a matching + there may be no NXT record proving the non-existence of a matching wildcard record, and the AD bit will not be set. - A query for an insecure delegation RRset (or a referral) will return - both the answer (in the Authority section) and the corresponding Opt- - In NXT record to prove that it is not secure. - - -Arends, et al. Expires May 2, 2003 [Page 10] +Arends, et al. Expires August 28, 2003 [Page 11] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 - Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NXT record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A RCODE=NOERROR, AD=0 @@ -570,29 +630,32 @@ Internet-Draft DNSSEC Opt-In November 2002 Authority Section: UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE - SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY + SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG DS SECOND-SECURE.EXAMPLE. SIG NXT ... Additional Section: - NS.UNSIGNED.EXAMPLE A ... - EXAMPLE. KEY ... - EXAMPLE. SIG KEY ... + NS.UNSIGNED.EXAMPLE. A ... - In the Example A zone, the EXAMPLE. node MAY use either style of NXT - record, because there are no insecure delegations that occur between - it and the next node, FIRST-SECURE.EXAMPLE. In other words, Example - A would still be a valid zone if the NXT record for EXAMPLE. was - changed to the following RR: + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NXT record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NXT record for EXAMPLE. + was changed to the following RR: EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT - However, the other NXT records (FIRST-SECURE.EXAMPLE. and SECOND- - SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure - delegations in the range they define. (NOT-SECURE.EXAMPLE. and - UNSIGNED.EXAMPLE., respectively). - - + However, the other NXT records (FIRST-SECURE.EXAMPLE. and + SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are + insecure delegations in the range they define. (NOT-SECURE.EXAMPLE. + and UNSIGNED.EXAMPLE., respectively). + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is + part of the NXT chain and also covered by an Opt-In tagged NXT + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be + removed from the zone without modifying and resigning the prior NXT + record. Delegations with names that fall between + NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or + removed without resigning any NXT records. @@ -605,23 +668,16 @@ Internet-Draft DNSSEC Opt-In November 2002 - - - - - - - -Arends, et al. Expires May 2, 2003 [Page 11] +Arends, et al. Expires August 28, 2003 [Page 12] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 6. Transition Issues Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant DNSSEC implementations will not recognize Opt-In tagged NXT records - as different from RFC 2535 NXT records. Because of this, RFC 2535 + as different from RFC 2535 NXT records. Because of this, RFC 2535 implementations will reject all Opt-In insecure delegations within a zone as invalid. @@ -668,45 +724,99 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 12] +Arends, et al. Expires August 28, 2003 [Page 13] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 7. Security Considerations - Opt-In allows for unsigned names. All unsigned names are, by - definition, insecure, and their validity (or existence) can not be - cryptographically proven. With Opt-In, a malicious entity is able - to: insert, modify, or delete insecure delegation RRsets within the - Opt-In spans of a otherwise secured zone. In addition, a malicious - entity is able to replay or delete wildcard expansions (if there is - an existing applicable wildcard) in the Opt-In spans of the zone. + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot by cryptographically proven. + + In general: + + o Records with unsigned names (whether existing or not) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilites are described in more detail in [10] (note in + particular sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NXT record. + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name). For example, if a resolver received the following response from the example zone above: - Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 14] + +Internet-Draft DNSSEC Opt-In February 2003 + + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A RCODE=NOERROR + Answer Section: + Authority Section: DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY EXAMPLE. SIG NXT ... Additional Section: - EXAMPLE. KEY ... - EXAMPLE. SIG KEY ... + The resolver would have no choice but to believe that the referral to - NS.FORGED. is valid. + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to nameserver under his/her control and place whatever + records needed at the subzone apex. While in particular cases, this issue may not present a significant - security problem, in general it should not be lightly dismissed. It - is strongly RECOMMENDED that Opt-In be used sparingly. In - particular, zone signing tools SHOULD NOT default to Opt-In, and MAY - choose to not support Opt-In at all. + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose to not support Opt-In at all. + + @@ -724,9 +834,11 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 13] + + +Arends, et al. Expires August 28, 2003 [Page 15] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 8. IANA Considerations @@ -780,9 +892,9 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 14] +Arends, et al. Expires August 28, 2003 [Page 16] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 9. Acknowledgments @@ -836,48 +948,98 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 15] +Arends, et al. Expires August 28, 2003 [Page 17] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 -References +Normative References [1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. - [2] 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] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-12 (work in progress), + December 2002. + + [4] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit", + draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002. + + + + + + + + + + + + + + + + + + + + + + + + - [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", - RFC 2181, July 1997. - [4] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - [5] Lewis, E., "DNS Security Extension Clarification on Zone - Status", RFC 3090, March 2001. - [6] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, - December 2001. - [7] Gudmundsson, O., "Delegation Signer Resource Record", draft- - ietf-dnsext-delegation-signer-09 (work in progress), September - 2002. - [8] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit", - draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002. + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 18] + +Internet-Draft DNSSEC Opt-In February 2003 + + +Informative References + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [7] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC + 2137, April 1997. + + [8] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [9] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name + System", draft-ietf-dnsext-dns-threats-02 (work in progress), + November 2002. Authors' Addresses Roy Arends - Bankastraat 41-E - 1094 EB Amsterdam + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede NL - Phone: +31206931681 - EMail: roy@logmess.com + EMail: roy.arends@telin.nl Mark Kosters @@ -892,9 +1054,15 @@ Authors' Addresses -Arends, et al. Expires May 2, 2003 [Page 16] + + + + + + +Arends, et al. Expires August 28, 2003 [Page 19] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 David Blacka @@ -948,9 +1116,9 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 17] +Arends, et al. Expires August 28, 2003 [Page 20] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 Appendix A. Implementing Opt-In using "Views" @@ -968,18 +1136,18 @@ Appendix A. Implementing Opt-In using "Views" of the insecure view. In addition, the only RRsets that may solely exist in the insecure - view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and - the zone apex NS RRset) MUST be signed and in the secure view. + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and the + zone apex NS RRset) MUST be signed and in the secure view. These two views may be combined at request time to provide a virtual, - single opt-in zone. The following algorithm is used when responding + single Opt-In zone. The following algorithm is used when responding to each query: V_A is the secure view as described above. V_B is the insecure view as described above. - R_A is a response generated from V_A, following RFC 2535 [4]. + R_A is a response generated from V_A, following RFC 2535 [2]. R_B is a response generated from V_B, following DNS resolution as per RFC 1035 [1]. @@ -987,7 +1155,7 @@ Appendix A. Implementing Opt-In using "Views" R_C is the response generated by combining R_A with R_B, as described below. - A query is DNSSEC-aware if it either has the DO bit [6] turned on, + A query is DNSSEC-aware if it either has the DO bit [9] turned on, or is for a DNSSEC-specific record type. @@ -1004,9 +1172,9 @@ Appendix A. Implementing Opt-In using "Views" -Arends, et al. Expires May 2, 2003 [Page 18] +Arends, et al. Expires August 28, 2003 [Page 21] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the @@ -1060,13 +1228,39 @@ Internet-Draft DNSSEC Opt-In November 2002 -Arends, et al. Expires May 2, 2003 [Page 19] +Arends, et al. Expires August 28, 2003 [Page 22] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 2003 Appendix B. Changes from Prior Versions + Changes from version 04: + + Added definitions for "signed name" and "unsigned name". + + Added text to make it clear that insecure delegations may have + Opt-In NXT records of the same name. Updated the example to have + one of these. + + Changed Server-side requirements from MUST NOT to SHOULD NOT and + added some basic description of what action to take in the face of + violating the delegation-only restriction. + + Relaxed requirement that servers drop negative wildcard proof from + MUST to MAY, reiterated the client requirement. + + Added section on Dynamic Update declaring it to be undefined wrt + Opt-In. + + Essentially rewrote the "Security Considerations" section. It does + not actually say anything different, but hopefully it says it in a + clearer fashion. + + Split references into Normative and Informative. + + Fixed the example zone and responses to match Delegation Signer. + Changes from version 03: Editorial changes for clarification only. @@ -1080,13 +1274,21 @@ Appendix B. Changes from Prior Versions Changes from version 01: - Changed to "delegation only". Strengthened "Security - Considerations" section. Added "Server Considerations" and - "Client Considerations" sections. Added AD bit requirement. + Changed to "delegation only". Strengthened "Security + Considerations" section. Added "Server Considerations" and "Client + Considerations" sections. Added AD bit requirement. Changes from version 00: Complete rewrite, altering approach from "views" to tagged NXT + + + +Arends, et al. Expires August 28, 2003 [Page 23] + +Internet-Draft DNSSEC Opt-In February 2003 + + records @@ -1116,21 +1318,66 @@ Appendix B. Changes from Prior Versions -Arends, et al. Expires May 2, 2003 [Page 20] + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 24] -Internet-Draft DNSSEC Opt-In November 2002 +Internet-Draft DNSSEC Opt-In February 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 (2002). All Rights Reserved. + 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 + 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 @@ -1140,15 +1387,24 @@ Full Copyright Statement English. The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. + 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 + + + +Arends, et al. Expires August 28, 2003 [Page 25] + +Internet-Draft DNSSEC Opt-In February 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 @@ -1172,5 +1428,29 @@ Acknowledgement -Arends, et al. Expires May 2, 2003 [Page 21] + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 28, 2003 [Page 26] diff --git a/doc/draft/draft-ietf-dnsext-insensitive-01.txt b/doc/draft/draft-ietf-dnsext-insensitive-02.txt similarity index 94% rename from doc/draft/draft-ietf-dnsext-insensitive-01.txt rename to doc/draft/draft-ietf-dnsext-insensitive-02.txt index 77e9c9df46d..c3d21c0f710 100644 --- a/doc/draft/draft-ietf-dnsext-insensitive-01.txt +++ b/doc/draft/draft-ietf-dnsext-insensitive-02.txt @@ -7,7 +7,7 @@ Expires August 2003 February 2003 Domain Name System (DNS) Case Insensitivity Clarification ------ ---- ------ ----- ---- ------------- ------------- - + Donald E. Eastlake 3rd @@ -46,7 +46,7 @@ Abstract - +Copyright (C) 2003 The Internet Society. All Rights Reserved. @@ -63,8 +63,8 @@ INTERNET-DRAFT DNS Case Insensitivity Acknowledgements The contributions to this document of Rob Austein, Olafur - Gudmundsson, Daniel J. Anderson, Alan Barrett, and Andrew Main are - gratefully acknowledged. + Gudmundsson, Daniel J. Anderson, Alan Barrett, Dana, Andrew Main, and + Scott Seligman are gratefully acknowledged. @@ -194,7 +194,7 @@ INTERNET-DRAFT DNS Case Insensitivity preceding them with a back-slash. This is the most commonly used technique for protecting back slash ("\") and period ("."). However, it is advisable to avoid using this on other than printing ASCII - characters. + characters to avoid implementation difficulties. @@ -283,7 +283,7 @@ INTERNET-DRAFT DNS Case Insensitivity 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 it the BINARY type [RFC + available. (The only such type defined so far is the BINARY type [RFC D. Eastlake 3rd [Page 5] @@ -333,8 +333,8 @@ INTERNET-DRAFT DNS Case Insensitivity [STD 13]. DNS Dynamic update has been added as a source of DNS data [RFC 2136, 3007]. When a node in the DNS name tree is created by such input, no case conversion is done and the case of ASCII labels is - preserved if they are for nodes being creted. However, no change is - made in the name label on nodes that already exist is the DNS data + preserved if they are for nodes being created. However, no change is + made in the name label on nodes that already exist in the DNS data being augmented or updated. It is quite common for higher level nodes to already exist. @@ -351,11 +351,11 @@ INTERNET-DRAFT DNS Case Insensitivity this case can easily result is obtaining data with "xyz.BAR.example". - The same considerations apply inputting multiple data records with - owner names differing only in case. From the example above, if an "A" - record is stored under owner name "xyz.BAR.example" and then a second - "A" record under "XYZ.BAR.example", the second will be stored at the - node with the first (lower case initial label) name. + The same considerations apply when inputting multiple data records + with owner names differing only in case. From the example above, if + an "A" record is stored under owner name "xyz.BAR.example" and then a + second "A" record under "XYZ.BAR.example", the second will be stored + at the node with the first (lower case initial label) name. 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 @@ -369,7 +369,7 @@ INTERNET-DRAFT DNS Case Insensitivity There is one additional instance of note, which reflects the general rules that output case reflects input case unless there is conflicting capitalization in the DNS database or the output case is - hidden by name compression. This is when a query matches a wild card + hidden by name compression. This is when a query matches a wildcard in the DNS database at a server. In that case, the answer SHOULD reflect the input case of the label or labels that matched the wildcard unless they are replaced by an indirect label which MAY @@ -542,7 +542,7 @@ Expiration and File Name This draft expires August 2003. - Its file name is draft-ietf-dnsext-insensitive-01.txt. + Its file name is draft-ietf-dnsext-insensitive-02.txt. diff --git a/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt b/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt new file mode 100644 index 00000000000..e49d805ed1c --- /dev/null +++ b/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt @@ -0,0 +1,386 @@ + + + Individual Submission + Internet Draft + Jae-Hoon Jeong + Jung-Soo Park + Kyeong-Jin Lee + Hyoung-Jun Kim + ETRI + Expires: August 2003 February 2003 + + + The Autoconfiguration of Recursive DNS Server and the Optimization of + DNS Name Resolution in Hierarchical Mobile IPv6 + + + Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 except that the right to + produce derivative works is not granted [1]. + + 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 provides the mechanism for the autoconfiguration of + recursive DNS server in mobile node and the optimization of DNS name + resolution in the hierarchical mobile IPv6 networks. Whenever the + mobile node moves into a new MAP domain, the region managed by + another MAP, in the hierarchical mobile IPv6 networks, it detects the + addresses of recursive DNS servers which are placed in the region and + replaces the old ones with the new ones for DNS name resolution. This + allows the time for DNS name resolution much reduced by using the + nearest DNS recursive server which exists in the region. Therefore, + the mechanism of this document can optimize the DNS name resolution. + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 1] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + + Table of Contents + + 1. Terminology....................................................2 + 2. Introduction...................................................2 + 3. Overview.......................................................3 + 4. HMIPv6 extension - Advertisement of Recursive DNS Server.......4 + 5. Neighbor Discovery extension - RDNSS option message format.....4 + 6. RDNSS selection by the Mobile Node.............................5 + 7. Detection of RDNSS failure.....................................6 + 8. Security Considerations........................................6 + 9. References.....................................................6 + 10. Author's Addresses............................................7 + + 1. Terminology + + This memo uses the terminology described in [3]. 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. + + 2. Introduction + + RFC 2462 [4] provides a way to autoconfigure either fixed or mobile + nodes with one or more IPv6 addresses and default routes. + + For the support of the various services in the Internet, not only the + configuration of IP address in network interface, but also that of + the recursive DNS server for DNS name resolution are necessary. + + Up to now, many mechanisms to autoconfigure recursive DNS server in + nodes have been proposed [5][6]. + + This document suggests not only the autoconfiguration of recursive + DNS server in mobile node that moves within the hierarchical mobile + IPv6 networks [3], but also the optimization of the DNS name + resolution in such networks. Whenever the mobile node moves into a + new MAP (Mobility Anchor Point) domain, the region managed by another + MAP, in the hierarchical mobile IPv6 networks, it detects the + addresses of recursive DNS servers which are placed in the region and + replaces the old ones with the new ones for DNS name resolution. This + allows the time for DNS name resolution much reduced by using the + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 2] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + nearest DNS recursive server which exists in the region. Like this, + because the mobile nodes use the recursive DNS server in the same + domain instead of the fixed recursive DNS server, the DNS name + resolution of the mobile nodes can be optimized. + + 3. Overview + + +-------+ +--------+ + | HA |---| RDNSS1 | + +-------+ +--------+ + | + | +----+ + | | CN | + | +----+ + +-----+ | + | | + | +---+ + | | + +-------+ + | MAP | RCoA + +-------+ + | | + | +--------+ + | | + | | + +-----+ +-----+ +--------+ + | AR1 | | AR2 |---| RDNSS2 | + +-----+ +-----+ +--------+ + + +----+ + | MN | + +----+ ------------> + Movement + + Figure 1: Optimization of DNS Name Resolution in HMIPv6 domain + + Whenever a mobile node enters into a new MAP domain of the visited + network, it receives the RA message including MAP option from Access + Router (AR) and performs the local binding update with the new MAP. + If the list of the addresses of the recursive DNS server (RDNSS) is + included in the RA message with the MAP option, the mobile node can + detect the new RDNSSs and select one of them for the DNS name + resolution. Like Figure 1, this scheme can reduce considerably the + time of the name resolution between the mobile node and the RDNSS. + Because the mobile node uses the nearest RDNSS in the same MAP domain, + RDNSS2, instead of the RDNSS in its home network, RDNSS1. When the + mobile node moves into another MAP domain, it replaces the old RDNSS + with the new RDNSS for the succeeding name resolutions. + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 3] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + 4. HMIPv6 extension - Advertisement of Recursive DNS Server + + Because this document considers only router advertisement for MAP + discovery, all ARs belonging to the MAP domain MUST advertise the + MAP's IP address. + + The information of the RDNSS in the MAP domain is stored in the MAP + by the network administrator and advertised as a new option through + the RA message with MAP option. There MAY be more than one RDNSS in a + MAP domain. A MAP advertises the RA message including the list of + RDNSSs in the same domain with MAP option. The RA message with MAP + and RDNSS options is propagated from the MAP to the mobile node + through certain (configured) router interfaces within the hierarchy + of routers. This would require manual configuration of the MAP and + RDNSS options in the MAP and also the routers receiving the MAN and + RDNSS options to allow them to propagate the options on certain + interfaces. + + Finally, the mobile node listening to RA messages receives the new RA + message and checks if the MAP is new or not. If the MAP is a new one, + the mobile node perceives it has moved into another MAP domain and + performs both the local binding update with the new MAP and the + update of the list of RDNSSs in the configuration of name resolution + with the new ones. From the next name resolution, the mobile node + uses the new RDNSSs. + + + 5. Neighbor Discovery extension - RDNSS option message format + + The mechanism of this document needs a new option in Neighbor + Discovery [7]. + + 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( = 3) | Pref | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + IPv6 Address for RDNSS + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 4] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + Fields: + + Type Message type. TBA. + + Length 8-bit unsigned integer. The length of the + option (including the type and length fields) + in units of 8 octets. The default value is 3. + The value 0 is invalid. Nodes MUST silently + discard an ND packet that contains an option with + length zero. + + Pref The preference of an RDNSS. A 4 bit unsigned + integer. A decimal value of 15 indicates the + highest preference. A decimal value of 0 + indicates that the RDNSS can not be used. + + IPv6 Address for RDNSS + The RDNSS IPv6 address. The scope of the address + can be any scope. + i.e., link-local, site-local and global. + The prefix of the address is be /64. + + When advertising more than one RDNSS, as many RDNSS options as the + number of RDNSSs are included in an RA message. + + 6. RDNSS selection by the Mobile Node + + When a mobile node perceives multiple RDNSSs through RA message, it + stores the RDNSSs in order into the configuration the resolver on the + node uses for DNS name resolution on the basis of the value of "Pref" + field and the prefix of "IPv6 Address for RDNSS" field in the RDNSS + option. The following algorithm is simply based on the rule of + selecting the nearest possible RDNSS, providing that its preference + value did not reach the maximum value of 15. When the distances are + the same, this algorithm uses the preference value to order the + RDNSSs. The mobile node operation is shown below: + + 1) Receive and parse all RDNSS options + + 2) Arrange RDNSSs in an ascending order, starting with the nearest + RDNSS and store them in the configuration for DNS name resolution + used by resolver. (i.e., the longest prefix matching between the + "IPv6 Address for RDNSS" field and mobile node's On-link CoA + (LCoA) MAY be used to decide the distance between mobile node and + RDNSS, how far away the mobile node is from the RDNSS.) + + 3) For each RDNSS entry, check the following; + - If the value of "Pref" field is set to zero, exclude the RDNSS + entry from the list of RDNSSs of the configuration for DNS name + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 5] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + resolution. + + Whenever the resolver on the mobile node performs the name resolution, + it refers to the address(es) of RDNSS in the configuration for name + resolution according to the current rule of selecting an RDNSS, + namely from the 1st RDNSS. + + 7. Detection of RDNSS failure + + A MAP placed in a MAP domain checks periodically if the RDNSSs + registered in the MAP are alive. Whenever the MAP detects the failure + of any RDNSS, it advertises the failure down to the hierarchy with a + new RA message including an RDNSS option of which "Pref" field has + zero for the RDNSS. When a mobile node receives the RA message, it + perceives that the RDNSS is out of work or the path to the RDNSS is + broken and excludes the RDNSS from the configuration for name + resolution. + + The dynamic detection of RDNSS failure in a MAP can be done by simply + pinging the RDNSS periodically (e.g., every ten seconds). If no + response is received, the MAP MAY try to aggressively ping the RDNSS + for a short period of time (e.g., once every 5 seconds for 15 + seconds); if no response is received, an RDNSS option MAY be sent + with a preference value of zero. + + 8. Security Considerations + + In order to guarantee the secure communication between routers, the + router advertisements sent between routers SHOULD be authenticated by + AH or ESP [3]. This security is essentially related to Neighbor + Discovery protocol security [7]. + + 9. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier, + "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft- + ietf-mobileip-hmipv6-07.txt, October 2002. + + [4] S. Thomson and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC2462. + + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 6] + DNS Autoconfiguration and Optimization in HMIPv6 February 2003 + + + [5] A. Durand, J. itojun and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002. + + [6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option", + draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003. + + [7] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for + IP version 6", RFC 2461. + + 10. Author's Addresses + + Jae-Hoon Jeong + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 1664 + EMail: paul@etri.re.kr + + Jung-Soo Park + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 6514 + EMail: pjs@etri.re.kr + + Kyeong-Jin Lee + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 6484 + EMail: leekj@etri.re.kr + + Hyoung-Jun Kim + ETRI / PEC + 161 Gajong-Dong, Yusong-Gu + Daejon 305-350 + Korea + + Phone: +82 42 860 6576 + EMail: khj@etri.re.kr + + + + + Jeong, Park, Lee, Kim Expires - August 2003 [Page 7] + \ No newline at end of file